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ABSTRACT 


This  thesis  demonstra-es  a  methodology  to  h=  used  by  a 
Program  Manager  to  allow  him  -o  procedurally  monitor  -chs 
design  development  of  an  embedded  waapons  system.  The  m-^th- 
odology  consists  of  a  unique  combination  of  several  software 
engineering  strategies  integrated  -o  form  a  powerful  manage- 
ment tool.  The  primary  objective  of  the  methodology  is  to 
provide  an  algorithnic  procedure  which  stresses  simplicity 
at  all  levels  of  abstraction.  Further,  the  system  must  be 
capable  of  generating  good  system  specifications,  good  docu- 
mentation, and  fully  understandable  products.  Sample  prod- 
ucts from  the  impleientat ion  of  the  methodology  on  the 
HARPOON  Shipboard  Command-Launch  Control  Set  (HSCLCS)  are 
provided    for  illustrative   purposes. 
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I.    INTRODOCTIOM 

A.       BACKGEOUHD 

Project  Management  within  th9  Navy  involvss  thr 
coordination  of  a  cciplex  set  of  managerial  and  technical 
responsibilities.  The    complexity      is    the      result   of      such 

factors  as  the  diversified  areas  ia  which  a  Program  Manager 
must  become  competent  and  the  size  and  complexity  of  modern 
weapons  systems.  The  task  is  aggravated  and  the  problems 
magnified  by  several  fac-ors  including  schedule  limitations 
and  resource  scarcity  (human,  monetary,  procedural  manage- 
ment tools,  etc).  Because  rhe  current  institutionalized 
procedures  are  inadequate,  a  Program  Manager  has  insuffi- 
cient tangible  guidelines  to  organize  a  project  in  a  way 
which    will   counter    and  mitigate   complexity. 

As  a  consequence,  most  projects  suffer  increasing  inef- 
ficiency which  is  paralleled  by  a  rise  in  disorganization. 
This  is  a  sure  result  of  unccntrolied  complexity.  One  of 
the  more  notable  areas  of  inefficiency  is  in  the  process  of 
specifying  the  desired  system.  Our  current  "m^ethodolcgy" 
all  too  cften  generates  nebulous  and  inaccurate  system  spec- 
ifications. This  situation  begins  a  snowball  effect  of 
increasinc  ambiguity  as  contractors,  bidding  on  the  project, 
attempt  to  design  a  system  to  meet  specifications  which  may 
not  be  complete  or  correct.  Therefore,  contractors  are 
forced  to  react  to  the  assumed  meaning  of  poor  specifica- 
tions rather  than  acting  toward  generating  a  clear,  logical, 
and  correct  design.  This  approach  to  generating  specifica- 
tions generally  results  in  the  contractor's  proposals  not 
meeting  the  user's  real  need.  Hopefully,  problems  are 
discovered   early;      the      later   they   surface,      the      higher   the 
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cost  to  correct  them.  At  bast,  however,  these  unde-ectei 
flaws  cause  the  needless  loss  of  much  time  and  money  (after 
the  project  is  given  tc  a  con-ractor)  regardless  of  when 
discovered. 

Tc  summarize,  complexity  is  inherent  but  controllable  in 
all  projects.  We  currently  dc  very  little  in  at-eraptir.g  tc 
control  it.  The  resulting  disorganization  leads  zo  time  and 
money   losses  mainly    due   to    poor   speci ficarions. 

E.       PURPOSE 

This  thesis  presents  a  procsdural  methodology  for  an 
embedded  weapons  system's  specif  icatior.  development  and 
design  documentation,  answering  tae  need  defined  in  the 
previous   section.  The   method      is   abstracted     from   a      case 

study  of  the  Harpoon  Shipboard  Command-Launch  Control  Set 
system  develDpment  initialized  by  Sentman  and  Marcney 
[Ref.  1]  and  refined  by  Olivier  and  Oisen  [Ref-  2].  It  is 
our  intention  to  show  that  by  using  this  methodology, 
complexity  will  te  reduced  and  the  following  improvements  to 
embedded    weapons   system    procurement    will    be   realized: 

1.  better   specifications  generated, 

2.  better   evaluation   of    contractor's    proposals, 

3.  increased      efficiency      within    the      project      manager's 
office, 

U.      better  pass    down   information   available   to    the   project 

manager's   relief,    and 
5.      develcoment   ccsts   lowered. 

C.       SCOPE   OF  THE    HETHCDOLOGT 

The  methodology  discussed  in  this  thesis  is  intended  to 
apply  to  the  development  of  all  embedded  computer  systems 
for  tactical  weaponry.  The  possibility  for  a  broader  scope 
exists        since        the      underlying        principles        are        widely 
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applicabls.  Howsvar,  further  genaralizing  of  the  method- 
ology is  net  appropriate  at  this  time  since  the  case  s-ady 
only    addressed    a   tactical   weapons    embedded   computer    sys-em. 

Figure  1.  1  shews  the  placement  of  t.he  Software 
Engineering  Methodology  within  the  initial  weapons  sysnam 
procurement  phase.  Figure  1.2  details  the  general  flew  of 
control  wirhin  the  Software  Engineering  Methodology.  This 
figure  also  shows  that  while  the  Contractor  Support  Services 
(CSS)  Contractor  develops  the  specifications  and  other  prod- 
ucts, -he  Program  Manager  lends  guidance  no  and  approves  the 
final  products  of  this  process.  The  guidance  supplied  is  of 
a  managerial  and  noz  a  technical  nanura.  Since  our  handling 
of  the  meThedology  is  concerned  winh  the  technical  issues  of 
how  the  procedures  should  be  performed,  the  thrust  of  cur 
discussion  will  be  aimed  at  the  CSS  System  Developmen-  block 
of   Figure    1.2. 

D.       BETHCDOLOGY    OFERVIEI 

It  was  cur  determination  that,  the  sysiem  design  method- 
ology, while  generally  only  an  abs-rac-r  ion  from  the  case 
s-udy,  must  possess  several  broad  traits  in  order  -o  meet 
the  objectives  stated  in  the  Purpose,  Section  B.  Where 
these  traits  were  not  innate  in  the  abstracted  procedures, 
the  methcdology  was  refined  -o  encompass  them.  These  traits 
are      introduced    below.  The      Conclusions      portion   of      this 

thesis.  Chapter  5,  discusses  why  each  of  -hese  traits  is 
necessary  and  how  they  permea-e   the    methodology. 

1.      Simplicity.       Simplicity    of   the    methodology    and   in  the 

understanding   of   its    goals   and    products   is    necessary. 

Onless  a    system   is   simple,      it    has    great    potential   to 

become      part    cf      the    complexity      problem    rather      than 

part   of    its    solution. 
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2.  Generator  of  Good  System  Specifications.  The  itie-^hcd- 
olcgy  must  prcduce  firm,  finsly-tuned ,  and  ir.-hcuse 
system  specifications,  No-=  that  the  term  in-hcuss 
refers  to  the  project  being  directly  supsrvis^^d  by 
-he  Program  Manager  regardless  of  where  the  actual 
work  is  performed.  To  be  most  effective,  however, 
xhe  actual  work  should  be  done  in  the  same  general 
Iccation  as  the  Program  Manager  (1.5.  the  same 
office,  office  building,  or  group  of  buildings). 
This  assumes  that  it  is  nsoassary  to  have  physical 
closeness  of  the  Program  Manager  and  the  prcj^-ct 
designer  in  order  to  achieve  their  continual  and 
effective   communication. 

3.  Generator  of  Gocd  Documentation  Products.  The  meth- 
odology must  produce  products  which  serve  as  a  proper 
passdown  to  reliefs  of  the  Program  Manager  and  his 
staff  memebers.  If  design  dacisions  and  system  spec- 
ifications are  not  properly  documented,  corporate 
knowledge   will  sursly  be   lost    upon    job   turn-over. 

4.  Generator  of  Understandable  Products.  The  method- 
ology must  produce  products  which  require  little 
formal  training  to  understand  and  use.  Also  it  must 
be  couched  in  terminology  aasily  absorbed  by  the 
average    Program  Manager. 

To  ensure  that  these  broad  system  traits  are  achieved, 
the  methodology  must  yield  products  which  possess  several 
specific  features,  inter  alia  understandability ,  reli- 
ability, efficiercy,  and  modif lability.  These  are  the  inajor 
goals      of      all      software    engineering      design      methods.  To 

achieve  these  specific  goals,  the  software  must  adhere  to 
many  structural  principles.  Ross,  Goodenough,  and  Irvine 
[Ref.    3]   provide  the    following   list   of    required   principles; 
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1.  Modularity.  The  modularity  principle  defines  how  to 
structure  a    software    system  appropriat 9ly. 

2.  Abstraction.  The  absxracrioQ  principle  helps  iden- 
tify essential  properties  common  to  sap-=r  f  iciaily 
different  entities. 

3.  Localization.  The  localization  principle  highlights 
methods  for  bringing  related  things  into  physical 
proximity. 

4.  Hiding.  The  hiding  principle  highlights  the 
importance  of  making  nonessential  implementation 
information  inaccessible.  It  enforces  constraint  on 
access  to   information, 

5.  Uniformity.  The  uniformity  principle  ensures  consis- 
tency. 

6.  Completeness.  The  completeness  principle  ensures 
nothing    is  left  out. 

7.  Ccnfirmabilit y.  The  confirmability  principle  ensures 
that  information  needed  to  verify  correctness  has 
been   explicitly  stated. 

The  methodology  must  meet  the  goals  and  objectives  detailed 
above  and  roust  possess  the  listed  traits.  It  must  also 
adhere  tc  all  of  the  principles  of  software  engineering 
design   strategies.  Only    by      religious   adherance      to    these 

criteria  can  the  complexity  of  designing  a  tactical  weapons 
system   be   significantly   reduced. 

There  is  one  fundamental  premise  of  this  methodology 
imperative  to  its  success:  the  system  software  development 
must  hold  top  priority  with  hardware  issues  being  deferred 
until   the      system  specifications      are    completed.  In    ether 

words,  the  software  decisions  must  drive  the  hardware  selec- 
tion. This  premise  has  been  reiterated  and  substantiated  by 
numerous  case  studies  performed  in  recent  years  among  them 
Barry  Boehm's  "software  first  machine"  [Ref.  4].  In  view  of 
the    fact    that  the  amcunt    of    computer    development    money    spent 
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en  software  is  saverai  times  the  amount  spent  on  hardware, 
this    is    a   icgical   prioritization   of    project   emphasis. 

The  basis  for  the  above  premise  is  that,  in  crier  to 
meet  the  goals  of  reliability,  modif lability ,  maintain- 
ability, and  to  a  large  degree  portability  in  software,  it 
must  be  procedurally  developed  independent  cf  and  wi-^hout 
regard  for  *he  hardware  on  which  it  will  execute.  A  major 
source  of  frustration  and  inefficiency  for  prograipmers  and 
maintainers  cf  current  tactical  weapons  system  software  is 
that  the  hardware  is  ingrained  in  and  an  inflexible  part  of 
the  system.  Consequently,  all  aodificatio ns  to  the  sof'^ware 
must  te  couched  in  the  limitations  of  the  system  hardware, 
limitations  iriiich  often  require  that  software  modifications 
disregard   all      principles   of   software    engineering.  If   the 

reverse  process,  that  of  allowing  the  hardware  to  drive  the 
software,  is  used,  these  hardware  deficiencies  are  quickly 
realized.  When  this  occurs,  the  potential  for  maintaining 
the    desired   goals  specified    above   is    greatly    reduced. 

Holding  off  on  the  hardware  specification  until  the 
methodology  is  completed  is  not  an  unrealistic  proposal. 
This  is  especially  true  in  light  of  the  high  frequency  of 
hardware  change  and  upgrade  which  most  weapons  system 
projects  experience.  The  basic  idea  is  simple:  it  is  rela- 
tively easy  to  find  shelf  hardware  to  implement  a  software 
system  while  the  difficulty  cf  achieving  the  design  goals 
listed  above  on  a  specified  piece  of  hardware  is  at  best 
unpredictable. 

A  standard  argument  against  having  the  software  drive 
the  hardware  is  that  there  are  many  hardware  systems 
purchased  (one  per  platform)  but  only  one  softwar=  system. 
This  basically  implies  that  cost  savings  are  more  a  function 
of  hardware  than  software.  This  argument  could  be  valid  if 
no  modifications  to  the  software,  which  destroy  its  struc- 
ture,   were    required.        But    the    probability   of   achieving  this 


17 


ever  the  system's  life  eye  1^  is  incredibly  small.  If  -h-^ 
structure  is  iesTiroyed,  the  future  sys-em  costs,  ev-n  in 
discounted  or  constant  dollars,  would  invariably  ba  many 
times   the   initial  cost  savings   in  hardware. 

Prior  to  initiating  the  procedures  of  the  methodology, 
the  Procram  Manager  along  with  his  staff  must  become 
familiar  with  the  current  project  documents  and  the  specific 
pur-0£3  and  mission  of  the  weapons  system.  The  first  stsp 
is  to  become  intimately  familiar  with  the  Eroad 
S-ecificaticns  detailed  in  the  Life  Cycle  Management 
Milestone  Zero  documentation,  th9  Justification  for  Major 
System    New   Start    (JMSNS).  These   broad  system   requirements 

are  developed  based  on  a  projected  mission  naed  by 
Deoartment  of  the  Navy  planners.  In-housa  refinement  of 
these  Bread  Specifications  due  to  changing  needs,  technical 
advancements,  and  inputs  from  the  fleet  (the  user  group) 
produces  a  set  of  Initial  Functional  Specifications.  Next 
the  Initial  Functional  Specifications  are  used  as  the  input 
to  the  methodology  to  design  the  proposed  system  utilizing 
the  .rinciples  of  software  engineering.  Again  Figur«  1.1 
provides    a   craphic   representation   of    this    flow. 

Three  disjoint  items  are  pertinant  to  the  overall  view 
of  the  methodology  in  this  stage  of  the  system  development. 
First,  the  system  design  is  most  likely  being  performed  by  a 
Contractor  Support  Service  (CSS)  firm.  This  is  because  the 
Proaram  Manaqar  nor  his  staff  have  the  time  and  in  many 
cases  the  ability  to  perform  these  tasks.  Second,  this  CSS 
firm  is  effectively  part  of  the  Program  Office.  It  should 
not  be  thought  of  as  a  separa-e  entity  but  rather  as  a  tech- 
nical representative  augmenting  tha  Program  Manager's  staff. 
This  closeness  ensures  that  the  Program  Manager's  desired 
s.stem  will  be  generated.  Third,  the  products  produced  by 
the  system  are  generated  and  updated  iteratively  (see  Figure 
1.2).  This   continual   refinement     of    tha      products   ensures 
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qcod  do cu mentation  of  the  perceived  system.  Thsse  it-^ms  of 
note  must  be  fully  comprehenced  by  the  Program  Manager  in 
order   to    most   effectively   utilize    thr    methodology. 

There  are  four  output  products  gensrated  and  refinsd  by 
usina  this  methodology:  a  datailed  ss-  of  sys-em  specifica- 
tions (the  final  Refined  Specifications)  ,  complete  Data  Flow 
Diaarams  and  Hierarchy  Charts,  the  designed  system  in  ADA 
S''st€m  Desian  Language  (SDL)  with  Module  Descriptions,  and 
D^sian  Decision  Documentation  (see  Appendices  A-E  which  show 
these    croducts      for    the    HSCLCS    design) .  Ccllecrively   they 

provide  all  the  documentation  rsguirad  zo  perpetuate  the 
corporate  meaory  of  the  project  and  to  give  a  complete 
picture  of  the  proposed  system.  Individually  they  provide 
the    followinq  functions: 

1.  System  Specifications.  These  are  the  detailed  speci- 
fications delivered  to  project  bidders  responding  to 
the  request  for  proposals.  The  higher  the  level  of 
refinement  of  the  specifications  when  en-^ering  this 
T:hase  of  weapons  system  development,  the  better  the 
chances  are  that  bidders  will  develop  sound  system 
crcposals   to    meet   the   real   need. 

2.  Data  Flow  Diagrams  (DFD)  and  Hierarchy  Charts.  These 
products  provide  a  graphic  display  of  th=>  system  by 
illustrating  the  system  functional  operation.  Using 
only  the  functions  to  be  performed  and  the  input  and 
outout  data  needed  to  perform  these  functions,  DFD's 
and  Functional  Hierarchies  ars  simple  to  generate  and 
use. 

3.  Design  in  ADA  SDL  With  Module  Descriptions.  The 
design  provides  a  procedural-level  illustra-^ion  of 
the  system.  It  documents  how  the  required  functions 
shewn  in  the  DFD»s  are  transposed  into  a  hierarchy  of 
croc=dures,  f uctions ,  and  tasks  for  data  manipulation 
in   order    to   perform    these    functions. 
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4.       Design      Decision    Docuaentation .  Whila   mosr      design 

decisions  appear  in  ether  docainsnts  (i.s.  the  speci- 
fications, design,  etc.),  some  are  not  feasibly 
includable  in  ether  produces.  The  Design  Decision 
Documentation  provides  a  place  to  store  pertinent 
facts  and   parameters    of   the   system. 

Thus  far  in  this  section  we  have  dealt  with  the  neces- 
sary goals,  principles,  ana  requirements  of  the  Software 
Engineering  Methodology  box  of  Figure  1.1  and  not  the 
mechanics  of  the  system.  This  is  because  the  high-level 
view  of  the  methodology  must  be  one  of  achievement  of  design 
objectives  and  not  in  the  procedures  necessary  to  produce 
documents,  Whether  or  net  these  objectives  are  met  will  be 
the  subject  of  Chapter  5,  Conclusions.  However,  to  provide 
a  proper  overview  of  the  methodology  details  Figure  1.3  is 
included  as  an  illustration  of  the  iterative  product  formu- 
lation phase.  The  det.ailed  discussion  of  this  flow  and  its 
subgoals   is   the    sole   subject   of   Chapter    4. 
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II.    BaCKGROOND    OF    THE    HABPOOM    CONTBOL    SET    DESIGN 

Recently  when  the  missile  subsystera  cf  the  HARPCON 
Weapon  System  was  upgraded  to  inclade  two  new  block  'anhar.ce- 
ments,  the  existing  HARPOON  Shipboard  Command-Laiinch  Control 
Set  (HSCICS)  was  rendered  inadequate  to  support  xhe  d-?sign 
features  of  the  new  blocks  cf  missiles.  Upon  examination  by 
analysts,  it  was  decided  that  the  existing  HSCLCS  software 
was  not  modifiable  and  a  new  design  effort  was  n?cessary. 
The  new  design  would  need  to  not  only  cover  the  recent 
missile  changes  but  also  be  fexible  enough  to  be  modified  to 
support  an-icipated  technical  achievements  in  rhe  near 
future.  This  chapter  will  introduce  the  basic  facers  of  -h« 
HARPOON  Weapon  System  and  provide  background  on  th^  work 
done  in  two  previous  theses,  (Ref.  1]  and  [Ref.  2],  -cward 
redesign   of   the    HSCLCS. 

A.       EXISTING   HARPOOH    WEAPON    SYSTEH 

The  HARPOON  Weapon  System  (HWS)  has  been  developed  to 
fulfill  the  requirements  of  the  Navy's  an-^i-ship  mission. 
The  HHS  is  currently  deployed  on  surface  ships,  submarines 
and  aircraft.  The  HWS  provides  over  the  horizon  an-ii-ship 
capability  in  all  wearher,  day  or  nigh-.  The  HWS  is 
comprised  of  the  missile,  launcher,  and  command- launch 
subsystems.  The      ship-launched        HARPOON      employs      either 

onboard  or  third  pariy  sensor  da-a  for  targeting  informa- 
tion. The  missile  is  a  "launch  and  forget"  weapon,  since  no 
ship   control  or    information    is   needed   after   launch. 

For  surface  ships,  the  HWS  control  and  data  processing 
functions  are  provided  by  the  HSCLCS  which  has  three  Tiodes 
of  operation:  normal,  casualty  and  training.  In  the  normal 
mode    the   major    functions   cf    the   HSCLCS   are: 


1.  Distribution   cf   powa  r  to   various   HWS   equipmant. 

2.  Selection   and   application   of   missile   warmup    powsr. 

3.  The  ability  tc  conduct:  various  automatic  and  manually 
initiated  tests  which  confirm  the  operability  of  the 
sysxem. 

4.  Distribution    cf  ship    motion  da -a    from    ship    equipment. 

5.  Selection,  transfer,  processing  and  display  of  target 
data. 

6.  Coordination  cf  the  selection  of  the  tactical  missile 
mode    and    type    of    fusing. 

7.  Selection  of  rhe  launcher  cell  containing  thc- 
intended    nissile  -o    be   launched. 

8.  Initialization  of  the  selected  missile  and  the  super- 
vision of  the  exchange  of  data  between  missile  and 
other  HWS   equipment. 

9.  Control    of   all  missile    firing    acxivities. 

These  functions  are  implemented  and  integrated  by  the 
HARPOON  Weapon  Control  Indicator  Panel  (H'^^CIP)  and  the 
HARPOON    Weapon    Ccntrcl  Console    (HWCC)  . 

The  HWCC  contains  most  of  the  HARPOON  system-unique 
command  and  launch  subsystem  equipment,  including  the  Data 
Processor  Computer  (DPC)  ,  the  Data  Conversion  Unit  (D?U)  and 
the  HWCC  life  support  equipment.  Together  these  components 
perform  data  processing  and  conversion  among  various  data 
types  and  provide  interfacing  with  existing  sensor  and 
ship's    equipment. 

The  WCIP  provides  visual  status  information  to  the  oper- 
ator during  formulation  cf  the  fire  control  problem,  and 
additionally  provides  manual  controls  for  the  operator.  The 
existing   WCIP   is   shown  in  appendix  E. 

The  i:pc  is  a  16-bit  microcomputer  with  15K  of  2PHCM. 
The  DPC  uses  an  assembly  language  program  to  provide  the 
following: 
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1.  Launch  envelope   parameter   validation. 

2.  Missile  comaand  generation  for  implementation  of 
missile  ccntrrl  parameters  including  ship's  attitude, 
search  pattern  orders,  engine  starting,  flight  t^rici- 
naticn  range,  altimeter  setting,  and  various  selec- 
table flight   trajectory   and  maneuvering  modes. 

3.  Pre-launch   testing. 

4.  Pre-launch   sequencing   and   timing. 

5.  Data    formatting  and    transfer   synchronization. 

The  DCU  processes  all  digital  and  analog  signal  conver- 
sions as  required  by  installed  hardware.  The  DCU  also 
provides  interfacing  of  target  data  inputs  from  the  Naval 
Tactical  Data  System  (NTDS)  Slow  Interface.  Ship  motion 
parameter   data    is   also  converted    in   the    DCU. 

E.       PBOBIEMS  &SSCX:iaTED    WITH    EXISTING    HSCLCS 

Since  the  existing  software  of  the  present  HSCLCS  is 
written  in  assembly  code  and  is  heavily  hardware  dependent, 
the  maintenance  cost  in  the  face  of  periodic  aissile  changes 
is  relatively  high.  Also  several  different  hardware  config- 
urations  exist    for    tre  different   firing    platforms. 

The  HSCLCS  also  has  numerous  deficiences  in  engagement 
planning  as  the  operator  cannot  fully  control  the  features 
of  the  new  block  missiles.  In  fact,  the  operator  has  no 
automated  assistance  in  engagement  planning  in  the  current 
system,  and  there  is  no  display  of  the  tactical  situation  at 
the  WCIP.  The  current  firing  solution  does  not  have  environ- 
mental factors  included  unless  the  operator  considers  them 
manually.  On  some  platforms  NTDS  was  intended  to  provide  the 
services  mentioned  in  most  of  these  deficiencies  but  the 
location  of  the  WCIP  has  inhibited  this  effort  and  indeed 
many    HARPOON   platforms  do  net   have   NTDS! 
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C-       BABPOON    WEAPON    SYSTEM   CONSTRAINTS 

The  ccnstraints  in  -his  saction  are  for  the  most  part 
technically  ori^anted.  Managerial  constraints  ar?;  to  be 
determined    by      coinpe-::enz    authority      az    a      la-ar    date.  The 

upgrade  of  -he  HSCLCS  must  be  abla  to  suppor-  zhe  new  block 
missiles  as  well  as  rhe  old  ones  sinca  the  old  missiles  will 
be    in   the   fleet    for    seme   time. 

The  implementation  of  the  upgrade  mus-  continue  to 
provide  all  previous  fuctions  as  wall  as  m-er  facing  with 
NTDS.  The  existing  launcher  hardware  will  remain  the  same 
and   the   physical   size  of   the   HSCLCS    must    be  -he   same. 

While  the  DPU  hardware  configuration  cannot  change,  the 
EPC  sof-ware  is  subject  to  change  as  necessary  to  iirplement 
the    upgraded  HSCLCS.  Although   the    current    software      is    in 

assembly  language,  this  is  not  a  requirement  for  the 
upgrade.  System  reliability  of  the  upgrade  must  meet  or 
exceed   existing    standards  for   the   HSCLCS. 

D.       SISTEH    DEFINITION   FOH   HSCLCS    UPSRADE 

A  dsxailed  discussion  of  the  system  definition  for  the 
upgrade   can   bs    found   in   [Ref.    1].      It    is   summarized   below. 

The  hardware  of  the  system  will  change  significantly. 
The  existing  DPC  will  be  replacad  with  a  commercially  avail- 
able CPU  with  additonal  memory.  The  WCIP  will  be  modified  to 
include  a  display  which  shows  the  current  tactical  situation 
and  programiaable  software  keys  to  irontrol  both  the  display 
and  engagement  planning  features  which  will  be  incorporated 
into  the  DPC  software.  A  hook  and  cursor  similar  to  those 
in  NTDS  will  also  be  provided  at  the  WCIP  for  the  operator.' 
A  display  processor  will  be  attached  to  the  WCIP.  The  DCU 
hardware  will  remain  the  same  however  the  software  must  be 
changed  to  accommodate  new  inputs  from  NTDS  and  environ- 
mental  data. 
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The  software  upgrade  of  ths  DPC  which  is  the  major  p=rt 
of  the  HSCLCS  focussd  upon  by  this  ■::hesis  is  to  sliniinat? 
the  existing  deficiencies  mentioned  in  the  section  E  of  this 
chapter.  Specifically,  a  software  plan  must  be  developad 
which  produces  adequate  software  that  provides  required 
capabilitities  and  is  flexible  enough  in  design  to  be  modi- 
fied   in   the    future    with    minimum  amoun-   of   blood   and   "cears, 

E.       STATE   0?  THE   OPGBADE 

The  software  upgrade  of  the  HSCLCS  has  been  the  subject 
of  the  two  praviously  ref=renced  thesas.  The  initial  thrus- 
cf  the  first  thesis  by  Maroney  and  Sentman  was  to  develop  a 
software  plan.  Figure  2.1,  and  complete  the  first  thrae 
phases.  Emphasis  was  placed  en  good  scf-cware  engineering 
techniques.  A  systems  requirements  analysis  was  conduc-ed 
which  produced  revised  system  spacif ications  and  laid  -he 
foundation  for  the  preliminary  design.  Daia  flow  diagrams 
and  subsequent  -ransfcrm  analysis  tschniqurs  described  in 
[Ref.  5]  were  used.  ADA  was  chosen  as  rhe  system  design 
language  in  anticipation  of  its  proclamation  as  the  standard 
DOD  SDL  and  because  ii.  lends  itsalf  so  well  ro  the  modu- 
larity concepts    necessary   for    modular    design. 

The  second  thesis  by  Olsen  and  Olivier  continued  the 
software  development  by  deriving  a  preliminary  design  from 
the  products  of  laroney  and  Sentman.  To  continue  the  plan, 
a  final  design  must  be  completed  along  with  detailed  docu- 
mentation. This  final  design  process  is  described  in  the 
methcdclccy   chapter. 
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Figure    2.1         Softwars    Plan  froa    Refer =nc9    1 
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III.    SOFTWARE    ENGINEERING    SNAPSHOT 

The  need  for  good  software  enginaering  --echniquss  has 
become  increasingly  evident  in  ths  past,  decade  with  the 
exponential  growth  of  software  development  and  maintenance 
costs.  Since  necessity  is  the  moth=r  of  invention,  the 
number  of  new  software  anginsering  methods  and  techniques 
has  also  grown  exponentially.  The  major  contributors  to  the 
methodolcqy  of  this  thesis.  Pressman,  De  Marco,  and  Booch, 
all  have  derived  systems  for  software  design  using  their  own 
particular  styles.  In  this  chapter  we  will  briefly  discuss 
those  styles  and  alsc  comment  on  some  other  software  design 
methodologies. 

Structured  design  was  first  publicized  by  Yourdon  and 
Contantine    [Eef.   6].  It    was   developed      to    be  used      as   the 

transition  tool  between  Structured  Analysis  and  actual 
imole mentation.  Composed  of  various  concepts,  measures, 
rules  of  thumb,  and  analysis  techniques,  this  method  with 
early  development  by  Ee  Marco  is  the  basis  for  the  Pressman 
design    methcdology. 

In  [Eef.  7],  De  Marco  describes  the  life  cycle  of  a 
software  project  from  requirements  analysis  to  specifica- 
tions. After  an  initial  survey  of  systems  requirements,  a 
data  flow  analysis  is  conducted  using  data  flow  diagrams. 
The  next  step  involves  creating  a  data  dictionary  from  the 
data  identified  in  the  data  flow  analysis.  At  this  point  in 
De  Marco's  methodology,  the  data  flow  diagrams  are  trans- 
lated into  a  set  of  specifications  using  a  subset  of  English 
called      Structured        English.  Structured      English        is      a 

specification  language  that  makes  use  of  a  limited  vocabu- 
lary and  a  limited  syntax.  The  vocabulary  consists  of 
imperative    verbs,   terms    defined   in   the   Data  Dictionary,      and 


28 


certain  r^.served  words  for  logic  formation.  The  mapping  of 
the  data  flew  analysis  to  the  Structured  English  specifica- 
tions is  fairly  algorithmic  but  uses  saveral  heuris-ics  that 
will  not  be  discussed  here.  De  Marco  also  explains  zhs 
desired  traits  of  a  design  based  on  the  specifications 
generated,  but  does  not  include  a  procedure  for  realization 
of    the    design. 

Pressman,  [ Bef .  5],  elaborates  on  all  phases  of  the 
software  life  cycle  and  gives  several  different  approaches 
to  design  such  as  data  flew  oriented  design  and  data  struc- 
ture oriented  design.  In  both  of  these  areas  he  carries  the 
software  development  process  through  the  prsliminary  design 
phase  but  does  not  address  specification  generaticr.  The 
data  flow  analysis  cf  Pressman  resembles  that  of  D9.  !!*arco 
but  his  transform/transaction  analysis  which  leads  to  module 
hierarchy  charts  ccntibutes  significantly  to  design 
realization. 

The  object  oriented  design  methodology  of  Booch  [Saf.  8] 
concerns  the  development  of  design  after  some  sort  of  data 
analysis    has     been   ccnducted.  Booch    does      not    indicate     a 

preference  as  tc  whether  data  flow  diagrams  or  any  ether 
kind  of  analysis  identifies  the  objects  in  a  project  as  long 
as  the  method  is  complete.  After  objects  are  identified  and 
given  attributes,  this  methodology  develops  a  system  design 
ty  stepwise  refinement  of  a  simple  prose  description  of  the 
system.  This    prose     eventually      is      transformed   into      ADA 

system  design  language.  No  guidance  for  conversion  of  the 
ADA  SEL  tc  structured  system  specifications  is  given  in  this 
methcdolcgy . 

There  are  several  system  analysis  and  design  tools  that 
have  teen  inplemented  but  have  not  gained  wide-spread  use. 
SADT  (a  trademark  of  SOFTECH,  Inc)  is  a  system  analysis  and 
design  technique  developed  within  the  Ycurdon  organization 
that      is   used     as  a      tcol  for      system    definition,         software 
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requirements  analysis,  and  system  design.  The  me-^hodology 
encompasses  technical  tools  and  a  well-defined  crganiza- 
tional  harness  through  which  the  tools  are  applied.  An 
automated  requirements  analysis  tool  is  SHEM  [ Eef -  5], 
where  elements,  attributes,  relationships,  and  struc-^.ures 
(all  parts  of  the  Requirements  Statement  Language  (RSL)  )  are 
combined  to  form  the  details  of  the  requirements  specifica- 
tion. SEEM  was  initially  designed  for  embedded  computer 
systems  and  requires  a  software  support  package  callsd  BEVS 
which  uses  computer  graphics  and  repor-^s  on  information 
flow.  Still  ancther        automated        tool  is        CADSAT 

(Computer-Aided  Design  and  Specification  Analysis  Tool) 
which  with  ESL/PSA  provides  an  analyst  with  several  capabil- 
ities.     These  include: 

1.  description      of  information      systems,      regardless     of 
applicaticn   area, 

2.  creation    of      a  data      base   containing      descriptors   for 
th?    informaticc  system, 

3.  addition,      dele+ion, and   modification      of   descriptors, 
and 

U.  production  of  formatted  documented  and  various 
rspcrts  on  the  specification. 
CADSAT  does  not  present  a  panacea  but  it  does  provide 
benefits  that  include  documentation  quality,  easy  cross 
reference  of  documents,  easy  modification,  and  reduced  main- 
tenance ccsts.  The  major  disadvantage  of  most  of  these 
automated  systems  is  that  they  require  a  considerable  amount 
of  trainirg  in  order  to  be  used  effectively.  However,  the 
concept  of  automated  design  is  here  to  stay  because  the 
benefits    far  outweigh  the   disadvantages. 

The  methods  described  above  are  only  a  few  of  the  many 
ways  that  software  development  is  being  conducted  today. 
The  design  tools  such  as  decision  tables,  flow  charts, 
HIPO-charts,      structured    flow   charts,         and  program    listings 
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abound.  It  is  outside  the  scope  of  this  thesis  to  discuss 
in  detail  all  of  the  methodologies,  bur  each  one  is  bas 3d  on 
the  design  principles  outlined  in  this  Thesis.  If  each 
methodology  produces  results  with  the  desired  charac-eris- 
tics,  only  through  extensive  experience  can  one  judge-  the 
relative   efficiency      cf   the    methodologies.  Since   software 

engineering  is  still  at  the  fledgling  stage,  we  can  only 
hope  that  -hese  methodologies  will  mitigate  -he  software 
crisis. 
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11,    DESIGN    ajTigpOLOGI 

The  methodology  for  rs fining  embedded  computer  weapons 
sysxems  specif  icaticr.s,  which  is  the  subject  of  -his 
chapxer,  is  required  to  possess  an  algorithmic  form  and 
logical  design  a-  all  levels.  By  levels  we  mean  the  levels 
of  abstraction  from  which  the  methodology  can  be  viewed. 
For  example,  an  outsider  to  the  project  offics  would  view 
the  methodology  as  a  "black  box"  which  inputs  broad  specifi- 
cations and  flee-  criteria  and  outputs  final  design  specifi- 
cations and  refined  design  products  (see  Figure  1.1).  The 
Program  Manager  would  be  heavily  involved  in  the  i-'=rative 
refinemenr  of  the  system  specifications  and  products  and 
consequently  would  see  the  methodology  as  a  generation  and 
refinement  tool.  His  "black:  box"  would  be  the  Contractor 
Support  Services  (CSS)  System  Development  block  of  Figure 
1.2.  Finally,  the  CSS  Contractor  would  view  the  methodology 
as  an  algorithm  for  froduction.  This  algorithmic  flew  is 
shown  in  Figure  1.3.  These  are  proper  abstractions  for  the 
methodology;  they  optimally  map  the  responsibilities  of  each 
of  the  incividuals  into  their  required  level  of  concern  for 
detail. 

This  chapter  is  concerned  with  introducing  a  me-^hodology 
at  the  CSS  Contractor  level  which  embraces  all  of  the  goals 
and  principles  and  proper  trade-offs  of  Software  Engineering 
design.  This  level  can  be  viewed  as  the  bottom  of  the 
abstraction  hierarchy  because  it  is  the  lowest  level  at 
which  the  entire  design  is  still  within  view.  It  is  our 
belief  that  if  this  level  cf  the  design  methodology  is 
well-structured  and  simple  then  the  entire  hierarchy  will  be 
so.       This   hypothesis    will   be    further    developed  in    Chapter   5. 
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The  methodology,  at  the  level  specified  above,  was 
conceived  and  tuned  using  the  following  pair  of  guiding 
rules:  it  must  have  a  simple,  saquential  form  and  it  mus- 
support  a  data  transform  driven  design.  By  data  -ransfori 
driven  design  we  mean  that  the  products  of  design  mus- 
project  hew  a  datum  is  interrelated  to  other  data  and  how 
data  is  transformed  as  processes  act  upon  it.  The  reasons 
for  these  basic  requirements  are  the  subject  of  the  two 
subsequent      paragraphs.  The      achiavement        of      the      first 

requirement  is  best  revealed  by  an  illustration;  Figure  4.1 
serves  this  purpose.  Notice  on  this  diagram  that  the  flow 
is  characterized  by  singular  inputs  and  outputs  with  a 
processing  block  between  them.  This  by  definition  is  xhe 
simples-  form  of  sequential  flow,  thus  the  first  rulr  is 
satisfied.  Figure  4.1  additionally  shews  that  the  first 
step  of  the  methcdolcgy  or  what  we  will  henceforth  refer  to 
as  the  first  methodology  function  is  to  manipulate  the  spec- 
ifications into  Data  Flow  Diagrams.  This  function,  data 
flow  analysis,  strictly  fellows  De  Marco's  procedure 
[Eef.  7],  a  procedure  which  fully  incorporates  the  cri-.eria 
for  data  transform  driven  design  listed  in  the  definition 
above.  It  follows  that  the  second  rule  is  additionally 
satisfied. 

There  are  several  strong  reasons  for  requiring  a  method- 
ology with  simple,  sequential  flow.  For  example,  the  usage 
of  such  a  methodology  is  straight-forward  and  easily 
grasped.  Further,  this  type  of  flow  tends  to  be  highly 
logic  rather  than  heuristic  oriented.  But  the  chief  reason 
we  wanted  simple,  sequential  flow  was  to  have  a  structure:* 
which  readily  supported  cur  methodology  model.  This  model 
views  the  system  as  a  series  of  functional  mappings,  e.g. 
data  flow  analysis  is  a  function  mapping  specifications  into 
a  hierarchy  of  Data  Flow  Diagrams  (see  Figure  4.1).  The  use 
of      the    wcrd     functicn  is      not      intended    to      imply   that      the 
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products,  i.e.  the  Data  Flow  Diagrams,  produced  by  the  meth- 
odology ar€  themselves  unique;  zhe  mapping  is  not 
one-to-one.  However,  we  suggest  that,  each  of  our  method- 
ology functions  map  their  input  produce  into  a  small  set  of 
output  products  which  is  a  realistic  partition  of  all 
possible  output  products.  By  realistic  partition  we  mean  an 
equivalence  subset  of  the  output  products  which  contains 
only  those  products  having  all  of  the  desired  structure 
principles  but  which  omits  those  grossly  inefficient  repre- 
sentations of  the  solution.  The  banafit  of  this  terminology 
is  it  enables  the  reader  to  view  the  methodology  from  a 
familar  technical  vantage.  Using  the  terminology  we  intro- 
duce our  hypothesis  that  these  functions  retain  the  proper- 
ties of  the  input  products  by  transmitting  them  to  the 
output  products.  In  other  words  the  methodology  functions 
are  designed  to  ensure  that  the  good  initial  structure  is 
carried   forward    throughout    the   methodology. 

The  main  reason  for  requiring  the  methodology  to  use 
data  driven  design  was  based  on  the  fact  that  real-time 
systems  (ell  applications  of  our  methodology  will  be  real- 
time systems)  are  easiest  to  design  this  way.  Shcoman 
[Ref.  9]  supports  this  hypothesis.  We  decided  on  data  flow 
design  because  the  graphical  nature  of  the  data  flew  model 
supports  DeMarco's  [Bef.  7]  belief  that  all  products  of 
analysis    functions    should  be   graphic. 

The  procedures  of  the  methodology  represent  the  compila- 
tion of  related  work  performed  by  several  distinguished 
pioneers  in  the  field  of  software  engineering.  But  the 
overwhelming  majority  of  contributions  came  from  three  indi- 
viduals: De  Marco;  Pressman;  and  Booch.  While  aach  cf  these 
men  see  the  problem  in  the  same  basic  light,  they  have  chan- 
neled their  research  efforts  into  different  facets  of  the 
problem.  The  De  Marco  contribution  consists  of  a  method  for 
transfcriing  system    specifications  into      a    set   of    structured 
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products.  Data  Flow  Diagrams,  which  reprssant  a  graphic 
solution      to     the        specification      rsquirements.  Pressman 

details  a  procedure,  transform/transaction  analysis,  for 
creating  an  abstracted  hierarchy  of  context-independent 
modules,  a  Function  Hierarchy,  from  Data  Flow  Diagrams. 
Booch,  claiming  to  have  achieved  objecx  oriented  design 
[Ref.  8],  contributes  a  method  for  developing  a  final  design 
given  a  Function  Hierarchy,  It  will  be  shown  later  that  the 
Eooch  procedure  is  in  fact  an  object  oriented  design  tech- 
nique. Figure  4.2  illustrates  the  specific  areas  of  method- 
ology coverage  by  each  of  the  authors.  Forrunately  for  our 
purposes,  these  areas  of  specialization  correspond  to  cne  or 
more  of  the  specific  functions  in  our  methodology  such  that 
all  of  them  (except  Specifications  Refinement,  which  is  our 
contribution)  have  been  significantly  researched.  Thus  only 
the  structural  interfaces  between  the  various  ccntributors 
need  to  be  specified  before  reducing  the  methodology  to  a 
series   cf   independent  functional    units    (see   section    B)  . 

The  effcrt  required  to  structurally  interface  between 
the  ccntributors  is  ninimal.  On  the  surface  this  may  appear 
puzzling  in  light  of  the  complexity  normally  encountered 
when  synthesizing  a  complete  product  from  disjoint  pieces. 
But  because  each  of  the  contributors  used  the  same  generally 
accepted  product  foruats  at  the  interface  points,  these 
problems  were  not  present.  No  interface  is  required  between 
the  De  Marcc  and  Pressman  portions  of  the  Methodology.  This 
is  because  Pressman  uses  all  of  the  rules  of  De  Marco  to 
produce  Data  Flow  Diagrams,  the  input  to  his  transform/ 
transaction  analysis.  Consequently,  we  can  view  this  situ- 
ation as  if  De  Marco  and  Pressman  "collaborated"  on  the 
interface.  Mor  is  ar  interface  between  Pressman  and  Booch 
required.  The  portion  of  Booch* s  method  we  use  requires 
only  a  function  hierarchy  as  input.  Since  this  is  the 
output  product  of  Pressman,  no  structural  interface  speci- 
fied   by   the   methcdolcgy   is    needed. 
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A.       HETHCDOIOGY    CEITEBIA 

^ •      §2^11  and  Principles 

Th€  goals  for  the  software  produced  by  the  method- 
ology (understandability r  reliability,  efficiency,  and  modi- 
fiability)  are  generally  accapzed  by  software  engineers  as 
those  cf  primary  importance.  In  gsneral,  this  list  <=-ncom- 
passes  all  of  the  relevant  attributes  necessary  to  ensure 
tha-c  software  will  realize  its  minimum  life-cycle  cost. 
These    goals    are    defined   as    fellows: 

1.  Understandability .  Unders-can  dability  is  that  pc-en- 
tial  for  software  to  project  a  clear  and  logical 
meaning.  It  is  achievable  in  all  systems  regardless 
of  the  complexity  if  bcth  ttie  suruc-ure  and  the  level 
of  abstraction  are  appropriate  for  the  proposed 
application.  It  mus-r:  be  stressed  tha-^  bcth  of  these 
properties  are  needed.  Having  merely  a  formatted 
structure  yields  a  legible  but  complex  product.  In 
order  to  realize  any  of  the  other  goals,  understand- 
ability   is  paramount. 

2.  Reliability.  Eeliability  is  the  ability  of  the  soft- 
ware to  function,  under  all  conditions,  as  the  speci- 
fications intended.  It  can  be  thought  of  as  freedom 
from  anofflolies  as  well  as  the  absense  of  blatant 
mistakes.  Beliability  also  encompasses  error 
recovery,  the  ability  of  the  program  to  continue 
processing  in  the  event  cf  non-catastrophic  system 
failure.  Achievement  of  total  reliability  is 
extremely  difficult  to  prove  even  in  a  system 
strictly  adhering  to  software  engineering  principles. 
It  is  impossible  to  prove  software  reliability  under 
lesser  conditions, 

3.  Efficiency.  Efficiency,  as  a  structure-driving  gcal, 
is   wrong.  Hcwever,      blatant      inafficiency   makes      a 
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sys-em  impractical.  The  efficiency  balance  aust  be 
achieved  by  first  adhering  to  all  oiher  go5.1s  and 
then  screening  for  gross  inaf ficiencies  which  can  be 
corrected  by  encapsulating  and  modifying  inefficient 
iucdules.  This   is      suppor-ad    by      Belady    and      Lehman 

[Ref.  10]  who  state  that  global  optimization  is  not  a 
practical  objective,  but  that  by  locally  optimizing, 
global  sub-optimization  can  be  achieved.  Thus  effi- 
ciency should  be  deferred  un::il  a  solid  sysrem  struc- 
ture is  established. 
4.  aodifiability .  Mcdif iabili-y  is  a  broad  term  which 
encompasses  the  ability  to  easily  change  sof-wars  for 
enhancements  or  errors,  for  performance  tuning,  and 
for  subsetting.  The  achievsraent  of  mocif lability  is 
difficult  because  the  effects  of  change  are  very  hard 
tc  predict.  Thus  mcdif lability ,  more  than  any  other 
goal,  universally  requires  the  strict  adherence  to 
all   of  the  software    engineering   principles. 

To  meet  these  design  goals,  the  principles  addressed 
in  Chapter  1  (modularity,  abstraction,  hiding,  localization, 
uniformity,  completeness,  and  con firmability)  are  the 
primary  attributes  required  of  the  methodology  products.  It 
seems  apparent  from  cur  readings  that  among  the  seven  prin- 
ciples, modularity  and  abstraction  are  uniformly  accepted  as 
the    dominant     re quireaents    cf      all  software.  This    is      not 

surprising  considering  that  these  software  qualities,  which 
logically  rsduce  larce  problems  into  manageable  subproblems, 
are    the    most     effective  reducers    of   complexity.  These   two 

principles  are  highly  coupled;  one  abstracts  to  reduce 
complexity  by  modularizing  and  modularizes  by  performing  a 
series  of  logical  abstractions.  Thus  they  should  be  thought 
of  as  iterative  subprocesses  of  some  higher  level  generic 
design      process.  A     more         detailed      description      cf      the 
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rGquirements  and  specifications   to   benchmark   the   achievement 
cf   modularity  and  abstraction   are   given    below: 

1.  Modularity.  As  seated  above,  i-  is  nearly  impossible 
tc  address  modularity  as  a  stand-alone  principle.  In 
its  simplest  form,  however,  modularity  can  be  consid- 
ered achieved  when  the  solution  -o  ^he  problem  is 
reduced  to  a  hierarchy  of  separately  addressable 
modules.  In  order  for  this  hierarchy  to  approach  t.he 
optimal  solucicn,  though,  it  must  have  a  good  balance 
between  two  inversely  proportional  measures:  the 
decree  of  module  complexity  and  the  degree  cf  inter- 
face  complexity. 

2.  Abstraction.  Abstraction,  too,  is  nor  an  independent 
concept.  It  can  be  considered  achieved  when  the 
problem  has  been  iteratively  expanded  (or  stepwise 
refined)  such  that  each  of  the  abstraction  levels  has 
a  solution  representation  which  captures  the  essense 
of  the  system  at  this  level,  but  specifies  no  unnec- 
essary complicating  details.  These  levels  of 
abstraction  provide  an  intellectually  graspable  view 
of   the  prcbleff's   solution. 

Of  the  remaining  principles  required  of  the  methcd- 
ology  the  most  important  ones  are  completeness,  indepen- 
dence, and  hiding.  While  the  presentation  of  these 
principles  may  tend  to  imply  that  they  are  of  second  echelon 
order,  this  is  not  true.  Rather  they  complete  the  system  of 
interwoven  requirements  of  the  methodology.  The  reason 
these  principles  are  presented  separately  is  because  unlike 
modularity  and  abstraction  these  ocncepts  are  not  univer- 
sally accepted  in  name  or  in  their  definition  by  the 
ccntributors.  Yet  each  of  them  is  either  directly  stated  or 
indirectly  supported  as  method  requirements.  For  example. 
Pressman      stresses      module    independence,        a      concept      which 
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requires  modularity,  abstraction,  and  completeness  as  prere- 
quisite principles.  Thus  Pressman  must  indirectly  support 
these      structural     concepts.  Further,         he      requires      the 

simplicity  of  module  interface  in  his  independence  concept. 
This  is  actually  a  loose  form  of  the  hiding  principle.  The 
key  point,  however,  is  that  his  method  builds  a  struc-ur  = 
vihich  allows  hiding  to  be  efficiently  appended  to  the  set  of 
principles  across  the  interface  with  rhe  Booch  method.  From 
a  broad  scope  this  implies  -hat  rhe  method  embraces  a  more 
stringent  set  of  principles  at  each  meihod  interface  ulti- 
mately yielding  a  design  which  adheres  to  all  of  the  neces- 
sary structure  principles.  This  idea  is  developed  in  the 
next  subsection.  The  specifications  for  achievement  of 
these   three    additional  concepts   are   given    below: 

1.  Ccmpleteness.  Completeness,  a  principle  stressed  by 
De  Marco,  is  a  critical  property  of  the  products  of 
our  methodology.  Its  criticaliry  is  especially 
apparent  when  performing  the  first  function,  data 
flow  analysis.  It  is  mandatory  to  ensure  that  each 
syst.em  specification  is  appropriately  captured  in  at 
leas-  one  Data  Flow  Diagram.  If  t.he  first  procedure 
of  the  methodology  produces  a  complete  set  of  Data 
Flew  Diagrams  then  all  subsequent  steps  will  have  a 
good,  graphical  representation  of  the  requirements  by 
which  to  benchmark.  Thus  achievement  of  completeness 
requires  the  assurance  that  each  methodology  function 
carries  forward  all  of  the  information  from  the  input 
product   into    the   output;   product. 

2.  Independence.  Independence,  the  chief  principle 
stressed  by  Pressman,  becomes  an  important  concept 
when  developing  the  Function  Hierarchy.  The  degree 
of  module  independence  can  best  be  qualitatively 
measured  by  first  measuring  the  levels  of  cohesion 
and   coupling    of  the    modules.       Cohesion   is    the   measure 
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of  module      single-mi ndadness   [  Ref .    5].  The    highesx 

cohesion,  which  is  the  goal  s-cata  for  maximizing 
independence,  is  achieved  when  every  module  has  a 
single  function.  Coupling  is  the  measure  of  mciule 
interconnecticn  and      interdependence   [Ref.    5].  The 

lowest  coupling  is  realized  when  the  interfaces 
between    modules  are    simples-c.  Low   coupling    is  also 

required  to  achieve  modular  independence.  Thus  inde- 
pendence is  achieved  when  the  design  products  have 
modules  which  address  a  specific  subfunction  of 
requirements  and  has  a  simple  interface  when  viewed 
frcm  other  modules. 
3.  Hiding.  Hiding,  a  principle  developed  by  Parnas  and 
highly  stressed  in  the  Booch  method,  implies  the 
prerequisite  achievement  of  completeness,  modularity, 
abstraction,  and  independence.  An  expansion  of  th- 
requireraent s  of  independence  that  distinguishes 
hidii^g  as  a  more  powerful  concept  is  that  these 
single  function  modules  must  have  a  simple  interface, 
the  interface  must  be  the  only  part  of  the  module 
visible  to  other  modules,  and  how  the  function  is 
accomplished  within  the  module  must  be  hidden 
[Ref.    11]-  This      invisibility    of      module      internal 

information  takes  us  one  step  beyond  what  these  ether 
four  principles  provide:  design  decision  encapsula- 
tion. Therefore,  achievement  of  hiding  requires  a 
conscious  effort  by  designers  to  delay  design 
decisions  until  the  latest  possible  "cime  and  when 
decisions  are  made  they  must,  be  encapsulated  and 
concealed   in    the   structure   of    the    design. 

Tim  Rentsch  has  boldly  defined  the  requirements  of 
the  nebulous  procedure  termed  object  oriented  design 
[Ref.    12],      He    states  that    the   essense   of   this   concept    is   an 
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adhsrerc«  to  the  principles  of  abstraction,  information 
hiding,  decision  encapsulation,  and  modularity.  Using  his 
definition  we  can  conclude  two  interesting  facts.  First, 
the  Booch  method,  as  Booch  himself  claims,  is  object 
oriented  design.  Second,  our  methodology,  because  of  its 
strong  adherence  to  the  five  major  structure  principles,  is 
also  an  example  of  object  oriented  design.  As  the  software 
"buzz  word"  of  the  1980's,  object  oriented  design  will 
undoubtedly   be    a   must   in   DO D  software    by   the    1990 's. 

2 •      Principle  Set  Synthesis 

Now  that  all  cf  the  design  concepts  required  in  th«=- 
methodolcgy  have  been  formally  presented,  it  is  necs^ssary  tc 
show  how  they  are  related  to  the  methodology  functions. 
This  includes  determining  the  point  at  which  each  of  these 
principles  becomes  an  active  concept  in  the  design.  The 
synthesis  idea  of  this  subsection  refers  to  the  fact  that 
all  of  tte  individual  principles  are  not  uniformly  visible 
throughout  every  function  of  the  methodology.  They  have  a 
point  dt  which  they  become  necessary  and  are  thereafter 
carried  forward  in  the  principle  set.  This  idea  that 
concepts  once  incorporated  in  the  design  are  thereafter 
ingrained  in  its  structure  is  justified  in  Section  C  of  this 
chapt  er . 

To  realize  a  principle  at  the  optimum  time  in  the 
design,  the  structure  must  be  capable  of  supporting  the 
inclusion  of  the  new  concept.  A  rather  simple  way  of 
viewing  this  requires  one  to  visualize  the  principle  to  be 
added  as  needing  a  set  of  prerequisite  traits.  For  example, 
the  prerequisites  for  independence  are  completeness, 
abstraction  and  modularity.  Thus,  if  the  current  structure 
of  the  design  contains  the  prerequisite  traits  then  the 
structure   will    be  capable   of    supporting    the   new   principle. 
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E€caus«  the  s<=t  of  principles  iDehaves  in  thf?  manner 
stated  atcve,  the  structure  requiremsars  becoms  increasingly 
more      stringent    as      the     design   iia      refined.  This   is      tha 

desired  effect  because  the  ultimata  objective  of  the  raethod- 
ology  is  to  produce  a  design  which  encompasses  all  of  the 
software  *raits  but  maintains  its  flaxibility  as  long  as 
possible. 

Tfce  initial  principle  s=t  for  the  methodology 
contains  the  concepts  of  abstraction  and  completeness.  It 
is  easy  to  see  abstraction  as  a  necessity  because  =ach  of 
the  functions  iteratively  refines  its  products  and  the 
refinement  process  is  based  on  levels  of  abstraction. 
Completeness  across  all  of  the  interfaces  requires  no  expla- 
nation; without  all  cf  the  parts,  the  design  could  not  be 
correct.  At  the  first  interface,  the  DeMarco/Pressman  junc- 
tion, the  structure  must  be  able  to  support  the  addition  of 
modularity.  The  fact  that  modularity  is  required  at  this 
point  in  the  design  is  no  surprise  considering  that  the 
purpose   of      the   Pressman      function  is      to   modularize.  The 

second  and  subsequent  iterations  of  the  module  heirarchy 
continually  refine  the  design  structure  to  achieve  low 
module  coupling  and  high  module  cohesion.  When  a  satisfac- 
tory trade-off  between  coupling  and  cohesion  is  made,  inde- 
pendence of  modules  is  achieved  thus  appending  independence 
to  the  set  of  principles.  With  the  set  of  principles  now 
containing  all  the  prerequisites,  the  Pressaian/Booch  inter- 
face structure  is  capable  of  supporting  hiding.  Figure  4.3 
illustratfrs   the    synthesis   of  the    principle    set. 

3.       METHCDOIOGY    COHPCNENTS 

^  •      5§1^  Z2l9.^   Analysis 

Data  flow  analysis  is  the  first  facet  of  the  evalua- 
tion     and      synthesis      phase      of      the      software      requirements 
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determination  process.  By  examining  tha  data  flow  we  get 
the  big  picture  on  what  the  entire  system  receives  as  input 
and  produces  as  output  and  the  patn  that  data  follows  in  the 
system   to      be   designed.  Daxa   flow      is   our      analysis    start 

point  because  we  do  not  want  to  get  bogged  down  in  specific 
areas  of  a  system  trying  to  define  functions  which  may  not 
be  clear  in  the  initial  analysis.  Dana  flow,  on  the  ether 
hand,  is  usually  much  easier  to  identify  than  flow  of 
control,  which  in  most  large  scale  projects  is  very  complex. 
The  primary  tool  we  will  use  to  examine  the  data  flow  will 
be    the      Data  Flow   Diagram    (DFD).  In   this   section      we    will 

briefly  describe  how  to  build  a  DFD  summarizing  the  methods 
detailed  in  [Ref-  5]  and  [Ref-  7]  and  also  what  the  DFD  can 
give  to  the  Program  Manager.  We  will  also  introduce  a  set 
of  example  DFD's  from  the  HSCLCS  system  that  will  be  used  as 
a  case  study  to  illustrate  the  methodolcgy  components 
throughout   the    chapter. 

a.      Data  Flow  Diagram   Definition 

The    data      flow    diagram  is   a      graphical   aid      for 

depicting      the      data      flow      of      the  software      system      being 

designed.      A  complete  understanding  of  the   DFD   is    imperative 

to   the   understanding    cf   the      design  methodology   described   in 

this  paper.  The  most  significant  characteristics  cf  DFD's 
are: 

1.  The   diagrams    are   graphic. 

2.  They    produce    natural    partitions  in   a   system. 

3.  They   are    multidimensional. 

U.      They   emphasize  the   flow   of   data. 

5.      They    de-emphasize   the   flow   of    control. 

Data  flow     diagrams   are      made   up      of    four      basic 
elements: 
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1.  Data  flows  represented  by  an  arrow  or  vector  from  the 
source  of  the   data   to   the    destination. 

2.  Processes  represented   by   circles    or    "bubbles". 

3.  Stored  information  (e.g  data  bases  or  files)  repre- 
sented by  two  horizontal  parallel  lines  wi-^h  a  mean- 
ingful label. 

4.  Data   sources    and   sinks   represented   by   boxes. 

Data  flow  can  be  broadly  defined  as  information 
flowing  between  two  processes  or  between  a  process  and  a 
source      or      a     sink.  There        are      several      general      rules 

concerning    data    flow. 

1.  Data    flow   names  are    hyphenated    and   capitalized. 

2.  No   two   data    flews   have   the    same   name. 

3.  Choose  navies  that  describe  rhe  data  explicitly  but  be 
concise. 

4.  Data    flow   should   not    represent   a    flow   of   control. 

5.  Data   flow   is^  not    considered  a    process    activator. 

Processes  invariably  show  some  amount  of  work 
performed  on  data.  Mere  explicitly,  a  process  is  a  transfor- 
mation of  incoming  data  flow  into  outgoing  data  flow.  Each 
process  bubble  should  be  numbered  and  given  a  unique 
descriptive   name. 

Sources  and  sinks  increase  the  readability  of 
the  DFD  by  showing  where  the  net  inputs  to  the  system  come 
from  and  where  the  net  outputs  go  to.  Sources  and  sinks 
differ  from  files  and  data  bases  in  that  they  are  considered 
to  be  cut  of  the  context  of  the  system.  Thus,  they  show  how 
the  internal  system  relates  to  the  outside  world.  Figure 
U.4  is  the  source/sink  diagram  for  the  Harpoon  System 
Command-Launch   Ccntrcl  System    (HSCLCS). 
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t.      DFD    Construction 

The  first  point  to  keep  in  mind  during  tha  data 
flow  analysis  is  not  to  try  to  learn  everything  at  on =  Time 
about  the  whole  system.  Think  top  down  by  conceptualizing 
the  high  level  data  flew  first,  defering  the  development  of 
the  low  level  data  flow.  Especially  avoid  addressing  any 
implementation  details  at  this  time  and  be  flexible  enough 
in  your  thought  process  to  start  over  from  scratch  if  road- 
blocks are  encountered.  Remember  "che  data  flow  analysis 
process   is   iterative. 

The  primary  input  to  the  da-a  flow  analysis  is 
the  Eroad  Specifications  of  the  system  to  be  designed. 
Direct  liaison  with  the  Program  Manager  and  prospective 
users  may  also  provide  additional  information.  A  key  point 
to  remember  during  each  phase  of  the  methodology  is  that 
decisions  concerning  design  that  are  not  specifically 
addressed  in  the  Broad  Specifications  must  be  documented  at 
the  pcint  of  the  decision.  These  design  decisions  will 
later   be   used  to   update  the    Eroad  Specifications. 

To  start  the  process,  identify  all  net  input  and 
output  cata  flows  and  list  them  around  the  border  of  your 
working  paper.  This  step  is  important  because  it  is  at  this 
point  that  you  define  the  context  or  scope  of  the  analysis 
to  be  conducted.  Data  flow  outside  of  the  scope  defined 
here    will  never    be    addressed  again. 

Filling  in  the  DFD  is  the  next  step  of  the 
process.  What  you  try  to  do  is  put  lines  in  your  diagram 
depicting  data  flow  and  try  to  connect  them  with  circles  or 
"bubbles"  where  a  data  transformation  occurs.  You  can  start 
from  the  inputs,  outputs  or  in  the  middle  whichever  is  the 
most  ctvicus  development  for  you.  Insure  flow  of  data  goes 
from  left  to  right  for  ease  of  reading  and  avoid  looping 
back    to   the   left.        If     a  loop   appears  necessary,       duplicate 
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the  process  bubble  that  is  looped  to  in  order  to  ks^p  the 
data  flow  inoving  righx.  Do  not  cross  lines  and  defer  naming 
the  bubbles  until  later.  When  all  of  the  data  flows  are 
connected  then  examine  each  bubble  ro  determine  if  some  data 
flow  occurs  within  a  bubble  to  achieve  the  bubble  output. 
If  so,  then  break  down  the  bubble  into  subprocesses  and 
create   lines      for  the  new      data    flows    discovered.  If   your 

working  paper  is  getting  flooded  with  lines  at  this  point, 
it   may   be  time    to   consider    a   leveled    DFD    approach. 

Basically  with  the  leveled  DFD  -he  first  sheet 
of  working  paper  contains  the  set  of  lines  and  bubbles  that 
were  thought  of  on  the  first  cut  while  subsequent  sheets 
contain  the  internal  development  of  bubbles  that  were  deter- 
mined to  contain  internal  data  flow.  The  leveled  DFD  system 
enforces  top-down  data  analysis  for  large  systems  which  in 
turn  naturally  induces  modularity  in  system  design  develop- 
ment. Figure  4.5  is  an  example  of  a  first  cut  system  DFD. 
For  convention  purposes  the  bubble  which  spawned  the 
internal  data  flows  will  be  called  the  parent  and  the 
bubbles  that  result  are  called  children.  For  numbering 
clarification  a  child  is  always  given  a  unique  number  which 
is  prefixed  by  the  parents  bubble  or  process  number.  As  a 
correctness  check,  always  be  sure  the  inputs  and  outputs  of 
the  children  correspond  to  those  of  the  parent  and  vice 
versa.  It  is  also  wise  to  only  expand  one  bubble  at  a  time 
to      insure   continuity     of  thought.  Data      bases    and      files 

accessed  or  modified  by  a  bubble  should  appear  on  the  high 
level  diagram  with  the  parent  and  the  appropriate  lower 
level   diagram      with    the   child.  To    be    sure,        upon   further 

analysis  a  child  may  develop  children  of  its  own  and  in  this 
way  various  levels  of  a  system  would  be  created.  Figure  4.6 
shows  how  one  bubble  of  the  HSCLCS  was  decomposed  to  form 
new   levels.  Note    that      this   particular      example   does      not 

balance  parent  and  child  inputs  and  outputs;  so  further 
refinement    is  required  to  capture   the    correct   data    flow. 
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Figurs  4.5   HSCLCS  Systam  Flow  Diagram 
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After  your  paper  is  fillad  with  lin€s  and 
bubbles,      ycu  should      label    the   data    flows.  Make   sur-?  -he 

names  of  the  data  flows  are  hones-c,  concise  and  descriptive. 
Be  careful  not  to  group  disparata  items  together  into  one 
data  flow  when  they  have  no  business  being  treated  as  a 
whole.  If  the  name  is  not  very  obvious,  it  is  possible  rhat 
you  need  to  rspartiticn  or  break  down  the  flow  into  levels. 
The  naming  process  is  designed  to  help  you  catch  errors  in 
your  data  analysis  so  be  prepared  -co  back  up  and  reconsider 
at    this    pcint. 

After  the  data  flows  are  appropriately  labeled, 
it  is  time  to  label  and  number  the  process  bubbles.  Use 
similar  guidelines  for  naming  the  bubbles  as  you  did  for  the 
data  flews.  Additionally , try  to  construct  names  with  a 
singular  action  verb  and  singular  object.  If  you  find  your- 
self caught  using  two  verbs  for  ona  bubble,  it  may  be  time 
tc    repartition. 

After  one  iteration  of  the  DFD  process,  a  good 
practice  is  to  set  it  aside  for  awhile  befora  beginning  the 
refinement  process.  The  refinement  process  consists  of 
examining  each  bubble  and  data  flew  line  to  determine  if 
further  decomposition  is  required.  Information  continuity 
is  required  on  all  refinements  in  that  all  incoming  and 
outgoing  data  flows  in  a  refinement  must  have  appeared  on 
the   previous  version.  Figures   4.7    and    4.8      show    a   initial 

decomposition  of  a  process  bubble  and  a  subsequent  refine- 
ment. The  iterative  process  continues  until  the  analyst 
feels  that  all  bubbles  and  data  flows  have  been  completely 
developed  or  until  further  decomposition  would  not  be  of  any 
practical  use  in  his  opinion.  Clearly,  experience  will  best 
teach  the  analyst  when  the  bottom  level  is  reached. 
Furthermore,  final  versions  of  DFD's  from  this  stage  of  the 
design  methodology  may  be  required  to  be  modified  during  the 
next    phases   of    the    methodology. 
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Examples  cf  D? D  development  for  the  HSCLCS  ^re 
contained   in  Appendix   A. 

c.      Using  the  DFD 

The  initial  use  of  the  DFD  is  to  converr  this 
product  into  a  Function  Hierarchy  via  the  transform/ 
transaction  analysis  technique  described  in  the  next 
section.  The  Program  Manager  will  use  the  DFD's  to  famil- 
iarize himself  with  the  basic  data  flow  cf  the  design  cf  the 
system  graphically  without  having  to  trace  the  flow  of  data 
through  a  lengthy  algorithm,  the  Broad  Specifications,  or 
the  final  design.  This  initial  graphic  understanding  of  the 
system  to  be  managed  will  also  allow  the  Program  Manager  to 
more  easily  understand  the  final  design  itself  and  to  be 
able  to  quickly  ccncep-ualize  the  flow  of  information 
refered   to    in  the   design    decisions   documentation. 

The  data  flow  analysis,  completed  in  the  form  of 
data  flow  diagrams,  will  lay  the  corner  s-one  for  the  devel- 
opment of  the  design.  This  process  must  be  done  carefully 
to  insure  that  the  foundations  for  modularity  and  implicit 
information  hiding  are  established  from  the  beginning  of  the 
system   development    process. 

2  •      Transf crm/Transacti  en   Analysis 

a.      Definitions 

Transform/transaction  analysis  is  an  algorithuic 
technique  for  developing  a  Hierarchy  of  Functions  which  is 
dependent  only  on  the  structure  cf  the  input  product,  the 
Eata  Flow  Diagrams.  As  the  method  name  implies,  there  are 
only  two  high-level  structural  forms  indigenous  to  data  flow 
diagrams:  transform  flow  and  transaction  flow.  The  method 
supposes  that  certain  fundamental  characteristics  exist  in 
all    software  systems:      data    must   be   input,    manipulated,      and 
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Pigure  4,8   HSCLCS  Display  Engagament  DFD  Rafineaen-  One. 
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output.  These  characxerist ics  are  broad  enough  in  na-uzr  to 
make  ths  technique  widely  applicable  to  many  types  of  soft- 
ware development.  Specifically,  -he  me-hod  is  highly  ccmpa- 
table  wi-th  the  development  of  real-time  systems  making  ir. 
ideal  for  cur  purposes.  The  reader  desiring  further  discus- 
sion   of   the   technique  should  consult    Pressman   [Ref.    5]- 

Transform  flow,  cur  fundamental  system  model  for 
all  data  flow,  envisions  the  system  as  inputting  and  output- 
ting  data  in  an  "external  world"  form  and  processing  (trans- 
forming) of  information  in  an  internal  form.  Transform  flow 
is  necessary  to  accommodate  both  the  user  who  must  input  and 
interpret  data  in  the  external  form  and  the  compu-^er  which 
must  process  data  in  the  internal  form.  Simply  stated,  if 
the  flow  of  information  can  be  viewed  over  time  as:  (1)  an 
afferent  flow  from  the  external  representation  of  the  inputs 
to  the  internal  representation;  (2)  a  process  flew  where  th? 
internally  represented  data  is  manipulated  to  produce  the 
desired  results;  and  (3)  an  efferent  flow  from  *:  he  internal 
representation  to  some  appropriate  external  display  for  thr 
information  then  transform  flow  is  present.  Figure  4.9 
illustrates  the  transform  flow  of  information.  Transform 
flow,  as  a  basic  model  for  all  software  development,  charac- 
terizes systems  very  simply.  They  input  data,  change  it  to 
an  internal  form,  process  it,  change  it  to  a  suitable  output 
structure,    and    output  it. 

To  solidify  the  above  discussion,  we  must  define 
afferent  and  afferent  flow  which  is  the  key  to  the  charac- 
terization cf  transform  flow.  Afferent  flow  is  information 
flow  along  paths  which  cause  the  gradual  transformation  of 
data  from  an  external  format  to  an  internal  format.  The 
transformation  can  be  viewed  as  a  funneling  of  the  informa- 
tion through  external/internal  interface  translators  toward 
a  central  processing  pcint,  a  transform  center.  Efferent 
flow   is    the     flow  of   information   outward      from   the   transform 
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Figure  4.9        Transform   Flow. 

Center  thrcugh  internal/external  interface  traaslators  to 
the  devices  which  will  display  the  results  of  thr  processing 
to   the   sjstem   user. 

Transaction  flow  is  characterized  by  a  process, 
called  a  transaction  center,  which  takes  an  ext.ernal  impetus 
and  causes  the  data  flow  no  be  directed  down  one  of  several 
paths  emanating  from  the  transaction  center.  The  path  taken 
is  determined  by  the  value  of  the  input.  Figure  4,  10  shows 
the  generic  form  of  a  transaction  flow.  An  easy  visualiza- 
tion of  transaction  flow  is  to  compare  it  with  the  standard 
case  statement.  The  case  statement  structure  corresponds  to 
the  transaction  canter,  the  case  variable  value  is  equiva- 
lent   to      the  external  impetus      (input),      and      the    subprocess 
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Figure    4.10        Transaction   Flow. 

called   wh€n   executing  the  case      statement   corresponds   to   the 
action   path   taken   in    the   Data    Flow  Diagram. 

t.      Procedures:    k  Case   Study 

To  present  the  transf orm/transactiDn  analysis 
technigae,  a  case  study  cf  the  HSCLCS  Display  Engagement 
Module  will  be  used.  The  Da-a  Flow  Diagram  pertinent  zc  -he 
case  study  is  shown  in  Figure  4,8.  A  general  rule  applicable 
^o  this  analysis  is  thai  the  entire  refinement  process  of 
the    Daza    Flow      Diagrams    must    be   compre-ed      before    cornmencing 
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the  procedure.  Otherwise,  the  proper  structure  of  the 
function      Hierarchy      cannot      be        assured.  Thr      procedure 

detailed  below  provides  a  template  for  a  generic  sysreii.  In 
some  relatively  simple  deve  lop  men-cs,  ail  of  These  steps  may 
net  be  needed,  e.g.  secondary  flow  analysis,  and  can  -here- 
fore    be   omitted. 

(1)  Flow  charac  teri sties.  The  first  step  of  the 
procedure  is  to  determine  the  characteristic  flow  of  ihe 
data.  It  is  possible  for  both  types  of  flow  to  exis-  on  i 
single  diagram;  this  is  the  case  for  our  ?xample.  Under 
these  circumstances  the  dominant  flow  pa-em  must  be  deter- 
mined. In  the  case  study,  -he  transaction  flow  abou-  the 
bubble  labsled  "Display  Engagement  Controller"  appears  to  be 
dominant. 

(2)  Marking  the  Diagraia .  Next  -:h=  Da-a  Flow 
Diagram  is  annotated  to  shew  tht  various  flew  boundaries. 
Because  the  transaction  flow  is  dominant,  we  will  apply  the 
rules  for  marking  the  transaction  flow  first  and  look  for 
the  af f sr 6n-/ef f erent  boundaries  to  mark  the  transform  flow 
second.  Ths  rules  for  transacrion  analysis  begin  with 
finding  and  isolating  the  transacrion  center.  As  the  defi- 
nition states,  the  transaction  center  is  that  procedural 
bubble  which  contains  multiple  radially  emanating  data 
paths.  Figure  U.  1  1  shows  the  isolation  of  -^he  transaction 
center  for  the  case  study.  This  identification  of  the  major 
flow  will  ultimately  develop  the  upper  level  modules  on  the 
function  Hierarchy.  To  provide  details  for  a  good  Hierarchy 
Chart,  further  refinement  of  the  flow  characteristics  must 
te  performed.  Since  all  of  the  secondary  flow  in  the  case 
study  is  transform  in  nature,  the  next  step  is  to  locate  the 
transforn:  centers.  They  are  easily  found  by  observing  the 
afferent  flow  into  selected  procedural  bubbles  and  the  effe- 
rent flow  cut  of  others.  In  the  case  study,  the  secondary 
flow   on   the   left   side  of     the   transaction    center    is    detailed 
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while  en  the  right  side  it  is  trivial  (see  Figure  U.12). 
The  right  side  is  trivial  becaase  tha  flow  boundaries  ar'e  in 
lowest  terms:  a  single  datum  afferent  flow;  a  single 
processing  bubble;  and  a  single  datum  efferent  flow.  Thus, 
or.e  would  expect  the  modular  breakdown  on  the  input  side  of 
the  hierarchy  to  be  somewhat  more  detailed  than  that  on  the 
controller   side.      Later   this   will   be    shown   to   be   the   case. 

(3)  Hierarchy  of  the  Dominant  Flow.  Once  the 
Data  Flow  Diagram  is  appropriately  marked,  the  first  cut 
hierarchy  for  the  dominant  flow  is  genera-ed.  The  fact  that 
flow  is  the  key  to  generating  the  hierarchy  supports  the 
supposition  that  the  structure  builx  during  me  data  flow 
analysis      will    be      maintained.  Both      types   of      flew      have 

strictly  mechanical  means  to  arrive  at  the  first  cut  hier- 
archy. This  is  because  of  the  way  data  flow  diagrams  are 
partition€d   when  marked. 

When  the  dominant  flow  is  transform  in 
nature  then  the  first-level  factoring  produces  a  two  level 
hierarchy.  The  upper      level    is      a    control      module   with     a 

generic  name  chosen  to  illustrate  the  global  function  of  the 
procedure.  The  second  level  contaiis  three  generic  control 
modules  with  the  following  functions:  one  coordinates  the 
afferent  information,  the  second  controls  the  processing, 
and  the  third  coordinates  the  efferent  information.  The 
process  bubbles  controlled  by  th-=se  thres  modules  are 
captured  by  the  afferen t/processing/ef ferent  boundaries 
marked   on   the  Data    Flew   Diagrams. 

Should  the  dominant  flow  be  transaction  in 
nature,  the  first-level  factoring  produces  a  three  level 
hierarchy.  The  upper  level  performs  the  same  function  as 
its  counterpart  used  in  transform  flow.  The  middle  level 
consists  of  two  controllers:  one  for  controlling  modules 
which  handle  the  input  flow  to  the  transaction  center  and 
one      for   controlling      modules      which      handle   the      individual 
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Figure  4.13        DcBinant  Plow   First   Cut   Hierarchy. 

paths    emanating      from  the      transaction   center.  The   bc-tom 

level  consists  of  a  group  of  modules  each  corresponding  to  a 
single  da-ca  path  out  from  the  transaction  center.  Figure 
U.13  shows  the  first  cut  hierarchy  for  the  dominant  trans- 
action   flow   of    the   case   study. 

(4)       Hierarchy      of   Secondary    Flows.  The    first 

cuts  of  the  secondary  flows,  which  are  handled  nex-,  are 
performed  in  exactly  the  same  manner  as  -ha  dominanr  flow. 
The  cnly  difference  is  that  the  top  level  module,  the 
ccntrcller,  for  secondary  flow  musi,  be  iden-ified  as  seme 
module  on  the  first  cut  dominant  flow  hierarchy.  Because 
the  secondary  flows  are  narked  in  relation  to  the  markings 
cf  the   dciiinant    flow    and     cannot    cross    already   existing   flow 
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Figure   U.  14        Secondary   Flow  First   Cut   Hierarchy. 

boundaries,  secondary  flows  are  always  encapsulated  within 
either  the  dominant  or  another  secondary  flow.  Thersfore 
the  top  level  ccntrcller  of  a  secondary  flow  must  map  into 
some  lower  level  module  of  the  dominant  flow's  (or  a 
controlling  secondary  flow's)  first  cut  hierarchy.  Finding 
this  lower  level  module  is  easy;  it  is  the  one  which 
performs  the  labeled  function  on  the  Data  Flow  Diagram. 
Figure  4.14  shows  the  first  cut  hierarchy  for  the  secondary 
flow. 

(5)  Second-Level  Factoring.  Secondary  factoring 
is  concerned  with  developing  the  lower  level  modules  in  the 
hierarchy.  It  is  basically  a  mechanical  process  of  locating 
modules  which  perform  the  same  functions  as  their  data  flow 
diagram  bubble  counterparts.  The  bubbles  contained  within 
the  flow  fccundaries  created  by  marking  -he  diagrams  are 
rsguired  to  be  mapped  into  modules  subservient  -iio  the 
controller  for  that  particular  subflow  (i.e.  the  afferent, 
processing  or  efferent  transform  flows  or  the  input  or 
dispatcher   transaction  flows). 
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It  is  not  mandatory  zo  have  a  ons-to-one 
mapping  betwesn  bubbles  and  modules  although  the  degr=e  of 
mechanicalness  of  the  process  is  dependent  upon  rhis.  This 
step  should  be  performed  as  mechanically  as  practical  to 
preclude  loss  of  information  due  to  premature  refinement. 
However,  mapping  strictly  by  mechanics  without  regard  for 
obvious  simplifications  fails  to  decrease  the  complexity  of 
further  factoring.  Practical  considerations  dictate  the 
outcome  of  the  second-level  factoring.  Figure  4.15  shows 
the  second-level  factoring  for  the  case  s-udy.  It  was  done 
in  a  mechanical  fashion  so  that  the  refinement  techniques 
discussed   below    could   be   more   adequately   shown. 

(6)  Refinement  Heuristics.  The  first  cut  struc- 
ture of  the  hierarchy  diagram  has  many  rough  edges.  The 
smoothing  process  is  not  well  defined;  it  applies  a  series 
of  heuristics  to  the  Function  Hierarchy  to  refine  the  system 
structure.  These  refinements  are  necessary  to  promot.e  t.he 
software  principles  discussed  throughout  the  thesis.  The 
following  heuristics,  offered  by  Pressman  [ Ref •  5],  meet  our 
needs : 

1.  "Evaluate  the  preliminary  software  design  to  reduce 
coupling  and  improve  cohesion."  If  a  module  encom- 
passes multiple  functions,  the  software  structure 
will  suffer  a  loss  of  cohesion.  Explosion  of  the 
mcdule  into  a  set  of  single-function  modules  regains 
the  cohesion.  If  a  module  has  ar.  unreasonably 
complex  interface,  coupling  will  increase.  Implosion 
of  the  function  into  the  parent  module  will  simplify 
-he  interface.  Note  that  implosion  and  explosion 
have  opposite  effects  on  coupling  and  cohesion.  The 
optimal  balance  between  coupling  and  cohesion  is  the 
goal    and    drives  the    module   refinements. 

2.  "Attempt  to  minimize  structures  with  high  fan-out; 
strive   for   fan-in   as    depth   increases."      An    example   of 
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a  high  fan-out  structure  is  a  trae.  This  type  of 
structure  does  not  attempt  to  abs-cract  similar  parts 
frcm  modules  and  make  them  subprccedures  to  a  multi- 
tude of  higher  level  modules.  It  is  therefore  a 
wasteful  structure.  Fan-in  at  a  low  level  generally 
indicates  a  well  abstracted  structure  with  singular 
purpose    modules. 

3.  "Evaluate  module  interfaces  to  reduce  complexity  and 
to  improve  consistency."  The  parameters  passed  to  a 
module  must  be  simple  and  consist.enr  with  rhe  func- 
ticn     of    the      module.  Otherwise      low   cohesion      and 

confusion  on  the  part  of  the  module  user  will  result. 
If  a  complex  interface  is  necessary  to  reasonably 
perform  the  desired  task  than  all  the  modules  in  the 
immediate  area  should   be   reevaluated. 

U.      "Strive      for      single-entry,  single     exit      modules, 

avoiding      pathological     connections."  This      simply 

warns  us  to  develop  modules  which  are  entered  at  the 
top  and  exitted  at  the  bottom.  Pathological  connec- 
tions are  branches  into  or  out  from  the  middle  of  a 
module.       They    must   be   religiously   avoided. 

(7)  Refinement  Process.  The  refinement  heuris- 
tics listed  above  fall  under  the  general  category  of  module 
independence      promoters.  Seeking   high      cohesion      and      low 

coupling  ty  the  implcsion/e xplosion  routine  is  necessary  in 
varying  degrees  to  gain  this  independence.  The  degree  of 
necessity  is  dependent  upon  the  level  of  refinement  of  the 
Data  Flow  Diagrams.  As  the  DFD's  capture  more  detail,  the 
number  of  correct,  efficient  Function  Hierarchies  decreases 
because  detail  limits  design  options.  Thus,  as  the  set  of 
DFD»s  approach  "maximum  refinement  the  transform/transaction 
analysis  process  approaches  a  fully  mechanical  algorithm. 
But      because     the      level     of   refinement      of      the      Data      Flow 
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Diagrams  is  realistically  (and  desirably  for  complsxity 
reduction  reasons)  rough,  heuristics  are  needed  to  refine 
the  Hierarchy  Chart.  As  indicated,  these  heuristic  proce- 
dures ar€  not  mechanical.  They  rely  on  common  sense 
decisions  by  the  user  to  transform  the  current  structure  to 
a  form  which  simplifies  the  design.  The  final  arbiter  is 
human    judgement. 

In    the  case    study,         several   refinements  can 
be   made.  Refer  to      Figures   4.15      and   4.16      throughout   the 

narrative.  First,  to  aid  abstraction  and  control  coupling 
all  references  to  data  in  databases  will  be  through  a  gener- 
alized data  interface,  an  abstract  database  management 
system  (EBMS).  Thus,  the  two  database  manager  modules  have 
been  replaced  on  the  final  hierarchy  by  a  generic  ccntrcller 
for  all  calls  to  databases.  It  is  beyond  the  scope  of  this 
discussion  to  refine  the  DEMS  module.  Next,  the  "Accept 
Display  Engagement  Command"  module,  which  performs  no 
processing,  was  for  simplicity  reasons  imploded  into  the 
"Accept      Inputs"    module.  Third,        the      processing   of      the 

"Process  Inputs"  module,  which  is  done  by  the  "Accept 
Inputs"  module,  and  the  processing  of  th^  "Output  Engagement 
Data"  module,  which  consists  of  only  a  parameter  pass,  are 
not  necessary  to  control  cohesion.  This  type  of  redundancy 
is  common  to  secondary  flow  analysis.  Consequently,  they 
were  imploded  into  the  "Input  Controller"  module.  Next, 
because  the  function  of  the  "Input  Controller"  and  the 
"Accept  Inputs"  modules  are  identical,  the  structure  can  be 
simplified  to  a  single  module  to  reduce  coupling  with  no 
loss  of  cohesion.  Note  that  the  final  name  chosen  for  this 
second  level  module  was  "Process  Inputs"  rather  than  "Input 
Ccntrcller"  or  "Accept  Inputs".  This  is  because  the  name 
"Process  Inputs"  is  the  most  descriptive  of  these  three 
candidate   names    for    the   module.  The   final    modification   to 

the    design,      that      of  abstracting   similar   data      from   the  two 
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scaling  modules,  attempts  to  "fan-in"  the  structure.  It  is 
shown  as  a  dotted  procedure  on  Figure  4.16  to  show  that 
factoring  is  possible   but   not    assured. 

3 .      ^c d ular    Development 

Modular  development  as  a  formalized  procedure  is  a 
technique  for  transforming  the  properties  of  the  Hierarchy 
Chart   structure    into    Module    Descriptions.  All    of   the   data 

required  to  define  the  modules  in  very  general  terms  is 
contained  in  the  structure  of  the  Function  Hierarchy.  The 
transformation,  while  seemingly  subtle  in  nature,  is  a  very 
important   step    in  the  methodology.  It   provides    an    elegant 

way  of  changing  the  system  specifications  from  their  totally 
graphic  form  into  a  short  narrative  form.  This  transition 
is  a  necessary  first  step  toward  using  an  SDL,  an  ADA  SDL  in 
our   case,   to  further    design    the   system. 

The  components  of  a  Module  Description  capture  the 
necessary  details  of  modules  commensurate  with  their  high- 
level  position  in  the  design  refinement  process.  While  the 
actual  format  of  the  Module  Descriptions  is  not  critical, 
the  contents  contained  within  them  is.  The  components 
provide  a  complete  description  of  the  module  for  this  stage 
of      the    design.  The      definitions    of      each      of   the      Module 

Eescription    parts  are  listed  below: 

1.  Module  Name.  This  name  must  be  the  same  as  the  one 
on  the  corresponding  module  of  the  Function 
Hierarchy. 

2.  Module  Function.  This  narrative  provides  the  purpose 
of  the  module  in  broad  terms.  It  should  reveal  a 
singular  purpose  in  order  to  meet  the  criteria  of  a 
module. 

3.  Supervisory  Modules.  These  are  the  modules  that  call 
this  module.  It  is  the  interface  with  the  supervi- 
sory   modules    which  is  explained   below. 
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4.  Module  Interface  (Parametsrs)  .  Here  the  ADA 
SDI-styled  parameters  are  listed  and  further 
explained  in  a  shcrr  narrative.  The  narrative 
reveals  the  basic  structure  for  the  data  type  of  the 
parameters.  The  interface  is  a  bridge  between  this 
module   and  all  of   its   supervisory    modules. 

5.  Subordinate  Modules.  These  are  the  modules  called 
within  the  body  of  -chis  module.  Their  interface 
definitions  are  handled  by  the  subordinate  module's 
interface. 

6.  Design  Decision  Encapsulation.  This  is  the  singular 
decision  which  the  module  hides  wizhin  its  body.  It 
must  be  a  singular  decision  to  meet  Parnas's  criteria 
for  a  module.  As  the  module  is  further  developed, 
additional  lower  level  decisions  will  usually  be 
necessary.  To  maintain  the  Parnas  singularity 
reguirement,  these  decisions  must  also  be  encap- 
sualted  in  their  own  procedural  structure.  Thus,  the 
Hierarchy  Chart  is  a  dynamic  product  being  continu- 
ally refined  as  design  questions  arise  and  decisions 
are    made    to   accommodate    them. 

Figure  U. 17  shows  a  recommended  style  for  module 
descriptions.  The  example  is  one  of  the  modulas  developed 
in  the  case  study,  THBEAT_ANALYS  IS_DISPLAY .  Viewing  Module 
Descriptions  as  the  first  step  of  the  design  in  the  SDL  and 
therefore  the  first  products  of  a  step-wise  refinement 
process  for  the  system  design,  we  present  the  descriptions 
in  ADA  SDL  comment  form.  Because  the  Module  Descriptions 
contain  the  necessary  details  ro  fully  define  the  modules, 
they  can  be  used  as  the  user  interface  in  the  ADA  SDL 
design. 

The  modules  should  be  developed  independently  by 
first    producing     the   Module      Descriptions  in      separate    files 
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-**  ** 

-**  Module:      THREAT    ANALYSIS    DISPLAY  ** 

-**  ~                      ~  ** 

-**  *« 

-*♦  Module   Function:  ** 

-**  To   query  the    database   management   sys-  ** 

-**  tern   fox  the  data    required    to   display  ♦* 

-**  the  threat    data   on   the    HSCLCS    console  ** 

-**  ** 

-**  Supervisory  Modules:  ** 

-**  PECCESS    INPOTS  ** 

-**  ~  «* 

-**  Module   Interface     (Paramezers)  :  ** 

-**  -    Threat:    out    Threat  Type  ** 

-**  ,    (This  is    a    buffer   for    holding   the  ** 

-**  current   threat  da*a    suitably   for-  ** 

-**  matted  so   that    the  task   THREAT    in  ** 

-**  the    package    DISPLAY   can    put   -he  ** 

-**  data   to   the    CRT.)  ** 

-*«  ** 

-**  Subordinate   Modules:  ** 

-**  DATABASE   MANAGEMENT    SYSTEM  ** 

-**  ~                            ~  ** 

-**  Design    Decision   Encapsulatp-d:  -* 

-**  The   interface    with    the    supervisory  ** 

-**  module   will  contain   the    structures    in  ** 

-**  CRT   grid  coordinates  compatable    with  ** 

-**  the  CRT  used.      This   moduxe   is   there-         *    ** 

-**  fore    an  abstract   interface    between    the  ** 

-**  data    positions   contained    in   the    data-  ** 

-**  bases    and   the    actual  CRT   positions.  ** 

-**  ** 

-♦*  ** 

_4e:(i:)c««44i:«c**4c*«:4c:tE«44:4E:4c4c4:«  **********************  ******** 
.*^* ************* *******  **********************  ******** 
.«********************************************  ******** 


Figure   4.17        Sa«ple   Hodale    DescriptioQ, 

and  then  writing  the  SDL  "code"  appended  to  the  Module 
Descr ipticns.  This  accomplishes  two  goals.  First,  it 
preserves  module  documentation  in  its  most  logical  place  and 
most  desiratle  form.  Second,  it  provides  physical  encapsu- 
lation of  the  module  encouraging  its  independent  use  in  seme 
other  system.  This  is  an  initial  step  toward  programming- 
in-the-large. 
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U  .      Transition    t c  ADA   Design 

The  transition  to  ADA  design  function  completes  the 
system  design.  Using  the  method  for  segregating  and  docu- 
menting the  Module  Descriptions  explained  in  th=  last 
section,  the  transition  builds  the  narrative  structure  into 
an      ADA-ccmpilable    System      Design      Language    "program".  It 

incorporates  the  stepwise  refinement  approach  of  detail 
abstraction   throughout  the    process.  The   steps    involv9d    in 

this  function  are  siiple  to  comprehend  and  follow  for  those 
moderately   versed   in   the   stepwise   refinement   technique. 

Stepwise  refinement  is  a  well-known  concept  in  th«^ 
software  engineering  community.  It  is  not  universally 
accepted,  however,  as  the  all-encompassing  detail  abstrac- 
tion methodology.  Because  it  is  very  useful  at  this  point 
in   our   methodology,         we   have   endorsed   it.  In   a   nutshell, 

stepwise  refinement  is  a  decomposition  procedure  which 
refines  a  previous,  higher -level  view  of  a  module.  It  is 
different  from  a  similar  technique,  top-down  design,  because 
unlike  the  top-down  method,  stepwise  refinement  is  limited 
to   developing  only    structured   constructs   within   modules. 

Before  proceding  with  the  refinement  process,  the 
Data        Flow     Diagrams,  Module        Hierarchy,         and        Module 

Descriptions  must  be  reviewed  to  identify  potential  modules 
for  packaging  and  to  look  at  the  concurrency  profile  (best 
shown  by  the  DFD*s)  of  the  system.  The  packaging  criteria 
consists  of  four  general  catagories  of  applications  for 
packages  €ach  with  multiple  subcategories.  The  broad  appli- 
cations are:  named  collections  of  declarations;  groups  of 
related  program  units;  abstract  data  types;  and  abstract 
state  machines.  Booch  [Ref.  8]  discusses  these  criteria  in 
detail.  Applying  these  criteria  to  the  case  study,  notice 
that        the       three        display  modules        along        with        the 

"PROCESS_INPDTS"    module     in    Figure   4.16    would      be    candidates 
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for      ADA   packaging.  This    is     bscausa      by  packaging      these 

modules  the  required  inputs  can  be  hidden  from  the 
"DISPLAY_ENGAGEMENT"  module  thus  realizing  both  a  grouping 
of  related  program  units  and  an  abstract  state  machine.  The 
criteria  for  ADA  tasks  als c  serve  four  applications  areas: 
concurrent  actions;  routing  messages;  managing  shared 
resources;  and  interrupt  handling.  Again  Booch  [Hef.  8] 
explains  these  applications  in  detail.  Returning  -o  the 
case  study,  these  three  display  modules  perform  functions 
independently  of  each  other  as  shown  on  Figure  U,S,  the  DFD, 
(i.e.  they  do  net  operate  en  the  same  input  parameters)  and 
consequently  are  candidates  for  concurrency  control  using 
the    ADA   task  mechanism. 

Tfce  procedures  of  the  stepwise  refinement  are  not 
particularly  rigid.  As  previously  stated,  the  main  idea  is 
to      deccmpose      ncdules     into      structured      constructs.  The 

following      steps   form     our      methodology      for    comple-ing      the 
design. 

1.  Write  the  procedure,  package,  function,  task,  etc. 
specification   including  all  of   its    parameters. 

2.  Write  the  body  name  cf  the  procedure,  package,  func- 
tion, task,  etc.  with  its  parameters,  a  short  narra- 
tive of  the  basic  flew,  and  the  appropriate  end 
statement. 

3.  Replace  the  narrative  of  the  body  by  the  high  level 
constructs  of  the   algorithm. 

4.  Continue  refining  the  algorithm  by  adding  detail 
until  the  desired  purpose  is  clear.  Give  no  more 
detail  than    necessary   to   meet    the   above  criteria. 

5.  If  during  this  process  the  need  for  design  decisions 
arises,  defer  the  decision  by  creating  a  subordinate 
module  specifying   only   its  interface. 

6.  Recheck  the  interfaces  for  clarity,  simplicity,  and 
ccnpleteness. 


75 


7.  Determine  the  design  decision  encapsulated  in  the 
module  and  check  that  it  is  entered  in  the  appro- 
priate Module   Description. 

Figure        4.18      shows  the      "THREAT^ANALYSIS^DISPLAY" 


task    THREAT    ANALYSIS   DISPLAY; 
(       with    EATABA3E    MANAGEMENT    SYSTEM; 
I      task    body  THRlAT    ANALYSI'S    DISPLAY    is 
I  type    THR   DBMS    Is 

I  record 

I  SHIP    NAME:  -    these    types    are    not 

I  SHIP~CLASS:  -    Dertinent   to   the    case 

I  WEAPONS  :  -   study   and  therefore 

I  ECM    EQUIPMENT:  -    not    developed 

(  ENG7JGEMENT_PLAN: 

end    record; 

THREAT    :    THREAT    TYPE; 

RECORD    FROM    THREAT    DB     :    THR    DBMS; 

END    FILE    :    "EOOLESNT 
I      begin* 

I  END    FILE    :=    false; 

I  while     (not    END    FILE)    loop 

I  THREAT    DB    MIJR    (RECORD^FROM    THREAT_DB,     END_FILE)  ; 

I  -   develop^the  CRT  coordinates    for   tho-s  display 

i-   consistent    with  the    known   coordinates   of   the 
-    actual  threat.      out   the   names   and   coordinates 
-  in  the   buffer,    TfiREAT. 
I  end   loop; 

I       end    THEEA-t    ANALYSIS   DISPLAY; 

! '         

Figure  4. 18        Saaple    Module  Design   in   &D&   SDL. 

design  which  completes  the  case  study  for  this  module. 
Stepwise  refinement  was  used  both  to  develop  the  specifica- 
tions of  the  task  and  the  flew  in  the  task  body.  Because 
all  of  tte  specifications  were  accurate  and  the  interface 
well-defined,  this  step  in  the  methodology  was  easily 
performed. 

5  •      Specification   Refinement 

One   of      the    primary    goals     of   the   methodology      is   to 
produce      tetter    specifications     and      at      this   point      in      the 
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process  the  existing  specifications  are  updated  by  incorpo- 
rating the  documented  design  decisions.  Also  if  certain 
decisions  were  deferred  until  now  such  as  exception 
handling,  it  is  the  time  to  include  them  in  -he  specifica- 
tions. On  the  first  iteration  of  the  methodology  -ha  input 
for    the   update    process  would   be  the   Broad   Specifica-ions. 

We  are  assuning  -chat  the  Broad  Specifications  are 
well  structured  and  in  accordance  with  current  directives. 
However,  at  each  review  point  of  tha  specifications  they 
should  be  screened  for  ambiguity,  confusing  description, 
overspecif ication,  orthogonality,  and  completeness.  The 
preceding  processes  in  the  methodology  will  iteratively 
ensure  completeness,  but  the  other  undesireabla  attributes 
must  be  found  editorially.  We  will  not  belabor  the  reader 
with  definitiors  of  the  attributes  but  they  can  be  found  in 
[Ref.    7]. 

A  sample  set  of  software  specifications  for  the 
HSCLCS  is  given  in  Appendix  F.  These  specifications  were 
the  product  of  a  first  iteration  of  the  methodology  for  the 
system  and,  if  approved  by  a  Program  Manager,  would  be  the 
final   refined  software  specifications. 

Although  this  section  of  the  methodology  appears 
short  in  comparison  to  the  long  algorithms  of  the  other 
methodology  components,  the  review  of  the  specifications  is 
extremely  important  and  should  be  given  an  equal  if  not 
greater  segment  of  the  methodology  time.  These  specifica- 
tions will  reflect  the  principles  incorporated  into  the 
ether  methodology  products  only  if  this  updating  process  is 
dons    with  care. 

C.       HETHCDOICGY    EVALOITION 

In     the   first      section      of  this      chapter      we    listed      and 
discussed  the  principles   and   goals     that   the    methodology   was 
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designed  to  produce.  In  this  section  we  will  show  how  the 
products   produced  conform  to  the    guidelines   specified. 

To  begin  with,  all  of  the  products  were  created  using 
concrete  algorithms  which  were  presented  in  a  manner  ^hat  a 
Program      Manager      could  easily      understand.  Although      the 

processes  did  include  some  heuristics,  uhe  thought  process 
behind   the    heuristics   was   explained  thoroughly. 

Each  of  the  products  exhibit  logical  design  flow  at  all 
levels  of  development.  The  stepwise  refinement  methods  in 
each  phase  of  the  methodology  insured  that  in  no  way  did  a 
cart  ever  get  in  front,  of  a  horse.  From  data  flow  diagrams 
to  design  to  specifications,  system  design  decisions  were 
deferred  until  the  last  possible  moment  in  order  to  maintain 
the  maximum  degree  of  flexiblility  and  to  enforce  abstrac- 
tion. This  logical  design  coupled  with  the  algorithicic 
methods  along  with  emphasis  on  simplicity  and  structure  in 
each  of  the  products  gives  the  methodology  one  of  the 
primary    goals:    understandability. 

The  four  basic  principles  (i.e.  modularity,  abstraction, 
independence,  and  hiding)  that  were  enforced  during  the 
phases  of  system  development  all  basically  contribute  to  the 
modif lability  and  maintainability  goals  of  the  methodology. 
Modularity  is  the  first  of  these  principles  and  the  entire 
system  development  process  steered  the  analyst  toward 
abstracting  common  characteristics  of  the  system  into 
modules.  The  abstraction  process  kept  details  of  design  at 
the      lowest    possible      level.  By     hiding    design      decisions 

within  modules,  a  design  decision  change  can  easily  be 
incorporated  into  each  of  the  products  by  simply  changing 
one      module    (ideally)  .  Furthermore    since      there   exists     a 

fairly  simple  mapping  between  products,  a  revision  could  be 
implemented  easily  across  the  board.  Since  independence  was 
also  one  of  the  principles,  strong  cohesion  and  weak 
coupling     of     modules  also      enhances      relatively      effortless 
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system  software  modification.  Clearly,  the  software  d<^v5l- 
oped        is        easily        modified  and        consequently        highly 

maintainable. 

The  iterative  nature  of  the  methodology  ensures  that  the 
products  will  be  reliable.  The  inherent  design  error 
checking  of  the  process  allows  the  designer  to  be  confident 
that  the  design  will  meet  all  previously  required  specifica- 
tions and  that  the  refined  specifications  produced  by  the 
methodolccy    effectively  encompass   all    design    parameters. 

To  simply  state  that  the  major  principles  used  to 
develop  the  individual  products  insures  that  the  desired 
characteristics  are  passed  from  phase  to  phase  may  not  ba 
enough.  Abstraction  and  completeness  are  natural  byproducts 
of  the  data  flow  analysis  methods  of  DeMarco,  but  do  these 
traits  proliferate  through  the  Pressman  and  Booch  module  and 
design  development  processes?  Does  the  modularity  and  inde- 
pendence gained  from  Pressman  carry  over  to  augment  the 
hiding      principle  emphasized      by      Boocn?  The   answers      are 

emphatic  affirmatives  based  on  the  iterative  nature  of  the 
principle   inclusion    process    of   the   methodology. 

Opon  clcse  examination  it  is  easy  to  see  that  the  prin- 
ciple inclusion  process  is  additive  in  nature.  Abstraction 
and  completeness  are  qualities  enforced  in  the  derivation  of 
the    Data      Flow    Diagrams.  Since  these      characteristics  are 

imbedded  in  the  DFD's,  which  form  the  basis  tor  the  Pressman 
transaction  analysis  phase,  they  are  necessarily  a  charac- 
teristic of  that  phase  also.  Additionally,  modularity  and 
independence  are  emphasized  on  top  of  the  abstracted, 
complete  foundation.  Similarly,  the  characteristics  brought 
forward  from  Pressman  to  the  design  development  of  Booch  are 
added  to  information  hiding  which  is  stressed  in  that  phase. 
In  this  way  we  are  guaranteed  that  the  ultimate  products 
possess   the     desired   traits.  Iterative   refinement      of   the 

processes  then    solidifies  the   placement   of   the  principles. 
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An  evaluation  of  th?  methodology  would  not  be  complete 
withouT  seme  comment  on  ADA  as  tha  system  design  language, 
however,  no  in-depth  analysis  of  ADA  will  be  given  because 
it  is  outside  the  scope  of  this  -hesis.  Besides  being  the 
DOD  language  of  the  future,  ADA,  with  its  package  and  task 
mechanisms,  is  especially  suited  -o  enforce  the  information 
hiding  principle  that  is  the  major  emphasis  of  the  Eooch 
phase  of  the  methodology.  Without  such  a  language,  the 
implementation  of  this  principle  would  be  tedious  if  not 
practically  impossible.  In  short,  ADA  is  no-  jusr  used  by 
the  methodology;  without  it  the  methodology  would  i.cz  be 
complete. 

Even  though  we  have  shown  that  this  methodology  will  be 
an  effective  tool  for  the  Program  Manager,  it  must  be 
stressed  that  if  all  of  the  guidelines  and  principles  are 
not  adhered  to  rigidly  thoughout  each  phase  of  the  process 
then  the  products  may  not  reflect  the  qualities  specified  by 
the  goals.  To  use  simply  modularity  without  hiding  in  mind 
could  result  in  software  that  is  net  easily  modifiable  while 
not  applying  all  of  the  rules  of  abstraction  could  yield  a 
very  inefficient  design.  The  major  distinguishing  trait  of 
this  methodology  from  others  such  as  FSL/PSA  and  SADT  is 
that  the  various  software  engineering  techniques  of  Booch, 
De  Marco,  Pressman,  and  Parnas  have  been  blended  to  form  a 
process  that  generates  products  that  can  begin  to  cut  the 
cost  of  software  maintenance  and  development.  To  employ  the 
process    you    must   be    well   schooled   in    the   basic  principles. 

It  is  apparent  that  the  goals  of  the  methodology  have 
teen  achieved  frcm  the  previous  discussion,  but  only  through 
implementation  of  the  process  can  it  be  evaluated.  The  only 
readily  obvious  improvement  upon  the  methodology  would  be  to 
automate  the  process  which  is  well  within  the  realm  of 
possibility  due  to  the  algorithmic  nature  of  the  method- 
ology. The  methodology      was   used      to      produce   the      design 
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products  for  the  HSCLCS  were  are  included  in  the  appendices. 
For  this  size  project  the  methodology  appeared  excellent. 
However,  the  i  npleienrors  found  that  increased  experience 
with  the  phases  produced  results  which  more  closely  adhered 
to  the  gcals  and  principles.  Further  proof  will  be  in  the 
pudding. 


81 


7.    CONCLOSIONS 

The  goal  of  this  thesis  was  to  aavelop  a  system  to  make 
the  Program  Manager's  task  of  monitcring  software  develcp- 
ment  of  embedded  weapons  systems  lass  complex  by  providing 
him  with  comprehensible,  easy  to  use  management  tools.  In 
the  previous  chapter  we  have  outlined  and  evaluated  a  meth- 
odology which  produces  the sa  managsment  tools,  and  in  the 
appendices  are  samples  of  the  products  of  the  methodology. 
The  roethccology  was  simple  to  implsmsnt  and  produced  good, 
complete  system  software  specifications  that  were  under- 
standable and  well  documented.  An  explanation  of  the 
Program  Manager's  procedure  in  utilizing  these  software 
development    tools   remains. 

The  Program  Manager  will  receive  broad  software  specifi- 
cations on  which  he  will  conduct  a  first  cut  evaluation 
prior  to  giving  them  to  a  Contract  Support  Service  (CSS)  for 
generation  cf  refined  specifications  using  the  methodology 
of      this   thesis.  After  a      specification    refinement,        the 

Program  Manager  reviews  the  methodology  products  and  feeds 
the  Refined  Specifications  back  to  the  CSS  if  necessary  for 
another  iteration  of  the  process  cf  refinement.  This  process 
continues  until  optinal  specifications  are  achieved  in  the 
opinion  of  the  Program  Manager  and  his  s-aff.  A  close 
working  relationship  between  CSS  and  Program  Manager  can 
accellerate  the  process  considerably.  Specifications  of 
high  quality  is  the  most  visible  product  of  the  process 
external  to  the  Program  Manager's  office,  but  the  other 
products  are  equally  important  to  che  management  of  a  soft- 
ware   system. 

The  Data  Flow  Fiagrams,  Module  Descriptions,  and  design 
with      documentation      are      of   high      value.  The      Data      Flow 
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Diagrams  provide  an  easy-tc-read  graphic  representation  of 
the  system.  The  Module  Descriptions  and  the  final  ADA 
Design  produced  give  further  simple ,  understandable  docu- 
ments that  a  Program  Manager  and  3specially  his  successor 
(relief)  can  use  to  grasp  the  details  of  the  software.  The 
Documented  Design  Decisions  are  even  more  important  to  -he 
pass-down  evolution  that  so  often  interrupts  the  continuity 
of  a  system's  development.  A  new  Program  Manager  can  not 
only  see  the  design  with  relative  ease,  but  he  now  has  a 
history  of  how  and  why  decisions  were  made  that  led  to  the 
design.  Corporate  knowledge  which  has  historically  been  the 
most  frequent  casualty  of  the  turnover  process  can  therefore 
be  a  survivor.  The  increased  insight  into  the  design  of  the 
proposed  system  also  puts  the  Program  Manager  into  a  batter 
position  to  evaluate  the  ultimate  system  contractor's  design 
proposals. 

Another  byproduct  of  better  specifications  is  the  poten- 
tial for  overall  system  development  cosxs  to  be  lowered.  By 
refining  the  specifications  "up  front",  there  is  a  reduced 
probability  tha-  the  contractor  will  discover  omitted  items 
in  the  specifications  that  require  costly  change  orders  to 
integrate  the  items  into  the  system.  Since  change  orders 
allow  contractors  to  adjust  the  cost  of  a  system  above  the 
original  bid,  reducing  the  number  of  changes  miniirizes 
overall  costs.  Further  in  the  costs  lifecycle  area  is  the 
capital  spent  on  the  maintenance  of  a  system  once  it  is 
implemented.  Modification  of  software  generated  by  this 
methodology  is  relatively  inexpensive  as  discussed  in  the 
previous   chapter.  In   most      cases   changes      in   requirements 

would  not  require  a  complete  systen  redesign  but  only  rede- 
sign of  the  module  affected.  Maintainance  costs  would  then 
be   obviously  lowered. 

The  most  intangible  benefit  gained  from  the  methodology 
is   the   economy    of  effort   gained  within    the   Program   Manager's 
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cffic€.  The  algorithmic  style  of  the  merhodology  and  the 
uniformity  of  the  products  provide  guidelines  for  the  soft- 
ware development.  The  lack  of  an  adequate  institutionalized 
procedure  for  software  development  organization  in  the  past 
has  caused  effort  to  be  wasted  performing  non -productive 
tasks.  Therefore,  the  increased  efficiency  due  ro  standard 
develccment    procedures  can    be    subs-antial. 

Software  development,  as  mentioned  before,  is  but  a  mere 
fraction  of  the  total  effort  needed  to  realize  an  embedded 
svstem  in  the  fleet.  However,  the  escalaring  cost  of  soft- 
ware makes  it  contribute  an  inordinate  amoun-^  to  -^he  total 
svstem  costs  including  system  maintenance.  It  is  Therefore 
imperative  that  the  bes-c  software  engineering  techniques  be 
used  to  reduce  the  exponential  growth  of  development  and 
maintenance  expense  and  to  ensure  rhe  Program  Manager's  task 
has  mirimum  complexity.  The  merhodology  promulgated  by  this 
thesis  is  a  major  step  in  developing  s-andardized  management 
procedures  for  software  development  that  will  reduce  costs 
and    crovide   more   maintainable   weapons    systems   to    the   fleet. 
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APPENDIX    A 
HSCLCS    DATA    FLOW    DIAGRAHS 

This     appendix    contains      the    HSCLCS      Data   Flow  Diagrams 

from    [Rsf.    1].      This    set   of    diagrams   is    by  no   means  complete 

and    is   crovidr'd    as    a      sample   methodology   product.  The   same 
caveat    a-pliss    to  each  of  the   appendices. 


85 


SOURCE 


HARPOON 

WCIP 
OPERATOR 


MANUAL 

DATA 
INPUT 


SHIP 
ENVIRON 

DATA 


SHIP 
PARAMETER  AND 
ENVIRONMENTAL  DATA 


NTDS 


NTOS  DATA 


LAUNCHER 
AND 

MISSILE 


TRANSFORMATION 


LAUNCHER 

MISSILE 
FEEDBACK 


SINK 


LAUNCHER 
AND 

MISSILE 


LAUNCHER  MISSILE  ORDER 


OPERATOR  DISPLAY 


HARPOON 
WCIP 

OPERATOR 


Figure    A-1        S-ouzca/Sink   Diagram. 
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Figure  i.2   System  Overviaw  DFD. 
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Figure    A. 3        Ccuplete   Manual  Process   Data  Flow    Diagram, 
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Figure  A.U   Opdata  Track  Data  Base  DFD 
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Figurs  1.5   Complete  convert  Environmantal  Data  DFD 
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Figure   1.6        Decode  Output  DPD. 
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Figure    a-7        Plan   Engagement   DFD. 
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APPENDIX    B 
HSCLCS    HIERARCHY    CHARTS 

The3€   are  the  HSCICS    Hierarchy  charts   froia  [Ref.    2]. 
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Figure  B. 1    First  Cut  Transform  Analysis. 
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Figurs  B.2        Befineoent  of  Transform  Analysis 
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Figure  B,3    Process  Input, 
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Figure  E.4    Piccess  Engagement 
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Figure  B.5        Process  Display, 
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Figure  3.6   Program  Design  Structure, 
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Figure  B.7   Transition  Strucrurs  of  Figura  B.6. 
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Jigure   B.8       Action    Path   Structiire  of   Track  Data   Base   Managf^r 
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Figure   B.9        Action    Path   of    Bnvironmental   Data  Base   Manager. 
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Figure  B- 10        Action   Path   of   Display  Hanager, 
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Figure  B.11         Action    Path   of  Engagement   Hanager. 
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Figure   B.12       Action   Path  of  Track  Data   Base   agr,    with   Heuristic. 
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iPPENDIX   C 
HSCLCS    MODULE    DESCRIPTIONS 

This      appendix      contain   descriptions      of    the      thirty  cna 
modules   of   the    HSCLCS   from    [Ref.    1]. 


C  0  nt  r  o  1 

Process   Input 

Ship    Parameter  Data   Base   Manager 

Environmantal    Data    Base   Manager 

Threat   Data   Base    Manager 

Convert  Ccordinates 

Type    Track 

Delete   Track 

Update    Track 

Course    and   Speed  Update 

Bearing,   Range,    and   Position    Update 

Add  Track 

Launcher  and    Missile   Assignmenr 

Launcher  and    Missile   Status 

Plan    Engagement 

Plan    Engagement    Data   Base   Manager 

Engageaenr   Data 

T  h  ^^  a^     Ds^  a 

Probability  of   Acquisition 

Uncertainty   Ellipse 

Display 

Menu    Display 

Launcher  ana    Missile   Status   Display 

Environmental    Display 

Engagement   Display 

Threat    Display 

AuTomatic   Engagement  Display 

Graohics  Display 

Manual   Engagement   Display 

Ship    Parameter    Display 

Track    Display 


1  - 

0 

2    - 

1 

3   - 

1.1 

a  - 

1.2 

5  - 

1.3 

6    - 

2 

7   - 

2.1 

8    - 

2.1.1 

9   - 

2.1.2 

10- 

2. 1.2. 

1 

11- 

2.1.2. 

2 

12- 

2.1.3 

13- 

3.1 

U- 

3.1.2 

15- 

3.2 

16- 

3.2.1 

17- 

3.2.2 

18- 

3.2.2. 

1 

19- 

3.2.3 

20- 

3.2.3. 

1 

21- 

a 

22- 

U.I 

23- 

a.2 

24- 

4.3 

25- 

u.u 

26- 

4.4.  1 

27- 

4.4.  2 

28- 

4.4.2. 

1 

29- 

4.4.3 

30- 

4.5 

31- 

4.6 
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**♦*«♦«♦«♦*«♦***♦♦***«*****  «**♦*******«♦****«****  ♦*5!£**;jt*;J: 


1.  Module    Nam?:       CONTBOL,    NDMEER    0 

2.  Module   function:    This    module   calls   all   oth9r   modules 

and    determines   the   program   flow. 

3.  Supervisory  modules:  None 

H.    Module   interface  (parameters)  : 

5.  Sutordinate   Modules:    Process   Input 

Launcher-Missile   Assignment 
Plan   Engagement 
Dis  play 

6.  Design    decision    encapsulated: 


:tcilli^c4c:i^:ltiif:4i:tL:i^iitf**  ******  *******  **********************  ******** 


1.  Module    Name:         PROCESS   INPUT,    NUMBER    1 

2.  Module    function:    Selects    subordinate    module  to    update 

corresponding   data   bases. 

3.  Supervisory    modules:    Control 
U.    Module   inter  face  (para  meters)  : 

5.  Subordinate    Modules:    Ship    parameter    Data   Base    Manager 

Environmental    Data   Base   Manager 
Convert   Coordinates 
Threat    Da-a   base   Manager 

6.  Design    decision   encapsulated: 


**************Hi**iic***lt*******4i*iit**ii::^4t  ************  ******** 


1.  Module    Name:     SHIP    PARAMETER    DATA    BASE    MANAGER, 

NUMBEB    1.1 

2.  Module   function:  Update  the    Ship  Parameter    Data    Base 

by  either    manual   or    automated    means. 

3.  Supervisory    modules:    Process   Input 
U.    Module   interface (paramet ers) : 

5.  Subordinate   Modules:    None 

6.  Desian   decision   encapsulated: 
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*:*:****«**4««  *********************************  ************ 


1.  Module    Nams:     ENVIECNMENT AL    DATA   BASE    MANAGER,     NUMBEH    1.2 

2.  Module    function: Update  the    Environmental   Data    Base   bv 

emher   manual  or    automated  means. 

3.  SUDerviscrv    modules:    Process   Input 
U.  Module   inter  face (parameters) : 

5.  Subordinate   Modules:    None 

6.  Desiqn   decision    encapsulated: 


***************************  ****************************** 


1.  Module    Name:    THREAT   DATA    EASE    MANAGER,    NUMBER    1,3 

2.  Module    function:  Update  the    Threat    Data    Base   by    either 

manual  means   or  through   use  or    a 
standard    chip   that   can   be    periodically 
updated    and   sent    to    all   ships    with 
HARPOON    capability. 

3.  Supervisory    modules:    Process    Input 
U.    Module   inter  face  (parameters)  : 

5.  Subordinate    Modules:    None 

6.  Design    decision   encapsulated: 


***************************  ****************************** 


1.  Module    Name:     CONVERT    COORDINATES,     NUMBER    2 

2.  Module   funotion:To  convert    all   the    inputs   to   update    track 

data    to    common  coordinates.    The    inputs 
can  be   manual,    from   own   ship's    tracking 
eguipment,    or   from   an    NTDS   link    from 
other    platforms. 

3.  Supervisory    modules:    Process   Input 
u.    Module   inter  face (parameters) : 

5.  Subordinate   Modules:    Type   Track 

6.  Desian   decision    encapsulated: 
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***  3)s  *****************************************  ***:(t  **:«i*«:4t:«t* 


1.  Module    Name:         TYPE   TRACK,    NUMBER    2.1 

2.  Module   function :Type   Track    determines    if  the   track   is   to 

be  deleted    from  the   data   base,    addpd   to 
the  data    base,    or    some   parameters   of  an 
existing    track   are    to   be   altered.    These 
actions    are   oerformed    by    selecting   the 
appropriate    subordinate    module. 

3.  Supervisory    modules:    Convert    Coordinates 

4.  Module   inter  face  (para  meters)  : 

5.  Subordinate    Modules:    Delete   Track 

Update   Track 
Add    track 

6.  Design   decision    encapsulated: 


********************************************************* 


1.  Module    Name:       DELETE   TRACK,    NUMBER    2.1.1 

2.  Module   function:  To  eliminate   tracks   from   the   data    base 

that   the   operator    determines   are   no 
longer  useful. 

3.  Supervisory    modules:      Type   Track 
U.    Module   inter  face  (para  meters)  : 

5.  Subordinate    Modules:    Track    Data   Base    Manager 

6.  Design    decision   encapsulated: 


«4c«:4(**4c:4c*:«e4c4E4c*:4c:4c:«c:4c:«c*4c:4c4c*«4c:4e  ****************************** 


1.  Module   Name:     UPDATE   TRACK,    NUMBER    2.1.2 

2.  Module   function :Tc  update  the    information    contained    in 

the  Track  Data    Base. 

3.  Supervisory    modules:    Type  Track 
U.    Module   inter  face  (para  meters)  : 

5.  Subordinate    Modules:    Course    and  Speed 

Bearing  and    range 

6.  Design   decision    encapsulated: 
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*«*  45  ***♦**«♦******  *********    ****************************** 


1.  Modul'T    Nama:     COORSJ    AND    SPEEE    UPDATE,    NUMBER    2.1.2.1 

2.  Module    function:     Ic  update    the    course    and    spe^d    infor- 

tion    on    each   track   contained    in   the 
Track  Data    Base. 

3.  Supervisory    modules:    Update  Track 
U.    Module   inter  face  (para  ffl-eters)  : 

5.  Subordinate    Modules:    Track    Data  Bass    Manager 

6.  Design    decision    encapsulated: 


4c3(c:tc:4c4c:4c:4c:4t:4c:tc:«c:4c:«e4ci4c  *  :«t*  *****  :«c  *«*:>*********  ♦ic  *********  *  **:*♦**** 


1.  Module    Name:       BEARING  ,RA  NGE    AND   POSITION    UPDATE, 

NUMEER    2.  1  .2.2 

2.  Module   function:     To  update   the   b^a  ring/];angs   and    posit  i 

(Lat-it  ude/Longit  uda)    mtcrmaticn   on 
each   track   in   the    Track   Data    Base. 

3.  Supervisory    modules:    Updare   Track 
U.    Module   interface  (parameters)  : 

5.  Subordinate    Modules:    Track   Data   Base    Manager 

6.  Design   decision    encapsulated: 


***************************  ****************************** 


1.  Module    Name:     ADD    TRACK,     NUMEER    2.1.3 

2.  Module   function:    To  allow   new    tracks    to   be   put    into    the 

Track   Data   Base. 

3.  Supervisory    modules:    Type   Track 
U.  Module  interface (parameters) : 

5.  Subordinate    Modules:    Track   Data   Base    Manager 

6.  Desian   decision    encapsulated: 


on 
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*******************  ******************************  ***4<**** 


1.  Modul€    Name:     LAUNCHER    AND    MISSILE    ASSIGNMENT,    3.1 

2.  Module   function:    Allow  the   operator  to    bypass    the 

engagement    planning    automatic 
selection    of   missile   cell 
and   simply   select   and    launch    the 
missile    manually. 

3.  Supervisory    modules:    Control 

4.  Module   interface (parameters) : 

5.  Subordinate    Modules:    Launcher   and    Missile    Status 

6.  Desicin    decision    encapsulated: 


i),^:/iii  4l  :lfi:ti^  Jiil^  4*  *********************4^********'ii***  ******  ****** 


1.  Module    Nam? :     LAUNCHER    AND   MISSILE    STATUS,    NUMBER    3.1.2 

2.  Module   function:    Tc   provide   currant  information    en   what 

launchers    (port   -    starboard)    are   ready 
tc  fire    and   which    and    what  types 
missiles   are   ready   to    fire. 

3.  Supervisory    modules:    Launcher   Missile    Assignment 

Engagement    Data 

U.    Module   inter  face  (para  meters)  : 

5.  Subordinate    Modules:    None 

6.  Design    decision   encapsulated: 


«:4c«4c:tc**4>«:»*«:4c«:^4c4i«**4  4*«*««4'*4:«*«4:4c4c*«*4e*:4c««:tc4c«:«c4c  ******** 


1.  Module    Name:     PLAN    ENGAGEMENT,    NUMBER    3,2 

2.  Module   function:    To  determine   the    optimum    engagment    plan 

for  a   given   targar. 

3.  Supervisory    modules:    Control 

4.  Module   inter  face  (para  meters)  : 

5.  Subordinate    Modules:    Plan    Engagement    Data   Base    Manager 

Engagement  Data 
Probability   of   Acguisition 

6.  Design   decision    encapsulated: 
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********«♦♦«********«:»*♦*************************  *#**:*::«e*:«: 


1.  Module  Name:   PLAK  ENGAGEMENT  DATA  BASE  MANAGER, 

NUMBER    3.2.1 

2.  Modul<r   function:    To  update   the    Engagement   Plan    Data    Base 

3.  Supervisory    modules:    Plan  Engagamant 
U.  Module   intarf ace (paramet ers) : 

5.  Subordinate    Modules:    None 

6.  Design   decision    encapsulated: 


:(e««:4c^4e4c^«4(:(e*^4c:(e4(**:4c**4E«4«*«  **********************  4t  *****  ♦'it 


1.  Module    Name:       ENGAGEMENT    DATA,    NUMBER    3.2.2 

2.  Module    function:     This    module    supplias   *he    data    needed 

by  tha    Plan    Engagement    module    to 
Generate   the    engagemant   plan. 

3.  Supervisory    modules:    Plan    Engagement 

U.    Module    inter  face  (parameters)  : 

5.    Subordinate    Modules:    Launcher    and    Missile   Status 

Threat  Data 


6.    Design   decision    encapsulated: 


***************  ****************************************** 


1.  Module    Name:      THREAT    DATA,    NUMBER    3.2.2.1 

2.  Module   function:    Tc   provide   the   information  contained   in 

the  the    module  to    the    Engagement   Data 
module    when   reguasted. 

3.  Supervisory    modules:    Engagement   Data 

4.  Module   inter  face  (  parameters)  : 

5.  Subordinaxs    Modules:    None 

6.  Design    decision   encapsulated: 


112 


:)i:4c*«3)e*««*4>**4n»c*:4e4<«*3t(4  4  4i«4c:(c«  4i«:tc:4c:ic:ic:4c4:«3)c  :ic:4e  4c :«(:(( :((«:(:  :4c*  Xc*  4c«3i'**«>ic3;c 


1.    Module    Nanis  :       PROEfiBILITY   OF    ACQUISITION,    NUMBER    3.2.3 


2.    Module    function:    Ic  determine    wha-    the    probability   i 

that    if    a    missils    is    fired  a-    a    qiv 


.s 
given 
target    thai:   the    missile   can   acquire 
and   hit    the  target 


3.  Supervisory    modules:    Plan  Engagemem: 

U.  Module   inter  face  (parameters) : 

5.  Subordinate    Modules:    Uncertainty   Ellipse 

6.  Desiqn   decision    encapsulated: 

:)c:4e«:«c  4:41*  **:«(«  4*4c  4c  «44::«c«  4  4341*  **4c  ****************************** 

1.    Module    Name:       UNCEBTAINTY    ELLIPSE,    NUMBER    3.2.3.1 


2.    Module    function:    Tc  compute   the    parameters   for 

ellipse    of   uncertainty    around 


>r    an 

.pse    ot   uncertainty    around    a 

contact's    posirion. 


3.  Supervisory    modules:    Probability   of   Acquisition 

U.  Module   inter  face  (  para  meters)  : 

5.  Subordinate    Modules:    Track    Data  Base    Manager 

6.  Desiqn    decision    encapsulated: 

«4c4c  4c  *********4c  ******  *******  **********  ***4c*  *******  ******* 


1.  Module    Name:       DISPLAY,    NUMBER    4 

2.  Module   function:    To  call    subordinate   modules   as    necessary 

tc  generate   required   displays. 

3.  Supervisory    modules:    Control 
U.    Module   inter  face  (parameters)  : 

5.  Subordinate    Modules:    Menu   Display 

Launcher   ana    Missile   Status    Display 
Env  ircnmen-cal    Display 
Engagement   Display 
Ship   Parameter   Display 
'];rack   Display 

6.  Desian   decision    encapsulated: 
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********************************************************* 


1.  Module    Nama :       MENU    DISPLAY,    NUMBER    4.1 

2.  Module    functicn:     Tc  accass   the    Msnu/State    Data    Bas-.    and 

display    the   raquirad   menu   when   called 
and    keep   track   of    the    state    Df    the 
program  . 

3.  Supervisory    modules:    Display 
U.    Module   interface  (paramet ers) : 

5.  Subordinate    Modules:    Menu/State  Data    Base    Manager 

6.  Design   decision    encapsulated: 


^t^c^c^e^^tt^ti^^^^^ti^^^cicTCt^^^^^^^i^te^^*  ***************************** 


1.  Module    Name:     LAUNCHER    AND    MISSILE    STATUS    DISPLAY, 

NUMBER    4.2 

2.  Module   function:    Tc  access   the   Launcher    and  Missile 

Status    Da-a    Base    and   provide    a    display 
of  the    information   contained    in   that 
cata   base. 

3.  Supervisory    modules:    Display 

4.  Module   inter  face  (parameters)  : 

5.  Subordinate    Modules:    Launcher    Missile    Data  Base   Manager 

6.  Design    decision    encapsulated: 


***************  4:4c:4c4c4::(c4e:4c:«c:(cj«c#:4c4:*:4c:4c:«c:tc:0c«**:»c:(c:4c:4c:4e:(c;tc:4e:^*:«e:4c:4i!^4i^:^:«[:4c 


1.  Module   Name:         ENVIRONMENTAL   DISPLAY,    NUMBER    4.3 

2.  Module   function:    To  access    the   Environmental   D^ta   Base 

and   provide   a   display   of    the    information 
contained   in   that    data    base. 

3.  Supervisory    modules:    Display 

4.  Module   inter  face (paramet ers) : 

5.  Subordinate   Modules:    Environmental    Data    Base   Manager 

6.  Desian   decision    encapsulated: 
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***************************  :»*******:«t****«***:ie«*«***:**«*^* 


1.  Module    Name:       ENGAGEMENT    DISPLAY,     NUMBER   4.4 

2.  Module   function:    To  graphically   disolay   the   flight    path 

cf  missiles   that   are    to   be   flown    ag ams' 
a  set   target.    Threat    data  on    the   -araet 
will  also   be   displayed.    The   engaaement 
plan   will    have  the   caoability    -o'be 
superimposed    over   the'aensral    track 
display . 

3.  Supervisory    modules:    Display 

4.  Module   interface  (parameters) : 

5.  Sutordinate    Modules:    Threat   Display 

Auxomatic    Engagement 
Manual   Engagement 

6.  Design  decision  encapsulated: 


♦  *******♦«♦«♦***♦***♦:»*****  ♦*****:}£******* *«*♦****  ««****  it* 


1.  Module    Name:       THREAT   DISPLAY,    NUMBER    4.4.1 

2.  Module   function:    To  access   the   Threat    Data  Base   and 

provide   a    display   of    the    information 
contained   in    that    data   base. 

3.  Supervisory    modules:    Display 

4.  Module  interface  (paramet ers) : 

5.  Subordinate    Modules:    Threat   Data    Base   Manager 

6.  Design   decision    encapsulated: 


4c«««««:4c:4[:(c4  4(*3(ci4c««:»4c««4  4«4c«:4c:te«:tc4c«:4e4:«:4(4c«**:)c*:4e:4c:4::4c:»c:ic:«:4c  ******** 


1.  Module    Name:  AUTOMATIC    ENGAGEMENT    DISPLAY,    NUMBER    4.4.2 

2.  Module   function: 


Engage 

Engagement    Plan    Data   Base. 

3.  Supervisory    modules:    Engagement  Display 

4.  Module  inter  face (paramet ers) : 

5.  Subordinate    Modules:    Engagement  Plan    Data    Base    Manager 

6.  Design   decision    encapsulated: 
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********«4*****  ♦****♦♦♦****  *)(c*:(t3}t********«:)t*«*:«c**:(ciejit*:ic:1t*** 


1.  Module    Nama :       GRAEHICS    DISPLAY,    NUMBER    4.4.2.1 

2.  Module    function:      To   provide    the    oparaTor    with   ths    capa- 
bility 

tc   manually   input   an   engagement    plan    fc: 
attacking   a   given   -arget. 

3.  Supervisory    mcdules:    Automatic   Engagement    Display 

Manual    Sngagemanr    Display 

U.    Module   inter  face  (parameters)  : 

5.  Subordinate    Modules:    None 

6.  Design    decision    encapsulated: 


«:{:>(:  4c  :«i:»:4i:4i:4[:»:4e4t^4c:ic  lie  *«:tc:4c«:»«4c4:*4e4«4:«^4t:f««4c«4c«^**4e:«c  *:<(«*  **««**«:^ 


1.    Module    Name:     MANUAL   EN3AGEMENT    DISPLAY,    NUMBER    4.U.3 


2.    Module   function:    To  provide   -he  operator   wii:h   the 

capability  to  manually  input  an 
engagement  plan  for  artackinq  a 
given  targ^ 


3.  Supervisory   modules:    Engagement    Display 

H.  Module   inter  face  (  para  meters)  : 

5.  Subordinate    Modules:    Graphics    Display 

6.  Design    decision    encapsulated: 

1.  Module    Name:       SHIP   PARAMETER    DISPLAY,    NUMBER    4.5 

2.  Module   function:    To  access   the   Ship   Parameter    9ata   Base 

and   provide   a   disolay   of    -he    information 
contained   in   that  "data    base. 

3.  Supervisory    modules:    Display 
U.    Module   interface (paramet ers) : 

5.  Subordinate    Modules:    Ship  Parameter   Dara    Base    Manager 

6.  Desian   decision    encapsulated: 
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***«:«:**********  ****ic«:^*****  *«:«t*  ********«****:«£  jjt*********:**: 


1.  Module    Name:       TRACK   DISPLAY,    NUMBER    4.6 

2.  Module   function:    To  access   the   Track    Data   Base    and 

provide    a   continuous  display   of   all 
tracks    being   maintained   m  -hat    dat; 
tase . 

3.  Supervisory   modules:    Display 

4.  Module   inter  face  (parameters)  : 

5.  Subordinate    Modules:    Track    Data   Base    Manager 

6.  Design    decision   encapsulated: 
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APPENDIX    D 
HSCLCS    ADA    DESIGi 

ABA    HSCLCS       design  from    [Ref.    2]. 


Fackaae   Update    is 

Task   Laiinch«r-Missil9_Status   is 

entry      Update  (Launcher-Missile      Status: 

in    Status  Type) 
End      Launcher-Missile_Status 
Task   Skip -Par  a  meter   is 

SHi^Z  Update  (Ship-Parameter:  in 

Ship-Parameter-  Type) 
End      Ship-Parameter 
Task   Er.vironment  is 

entry    Update    (Environment.:    in    Environment-Type) 
End     Environment 
Task   Threat   is 

entry    Update    (Threat:    in  Threa--Type) 
End      Threat 
Task   Update-Track  is 

entry    Add     (Track:    in   Track-Type) 

entry    Delete    (Track:    in   Track-Type) 

entry    Modify    (Track:    in   Track-Type) 
End      Update   Track 
End    Update 
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Pack_a5e   Auto-Engagement   is 

P£2£Sii2Ii   A-Engagemsnt       (launchar-Missile-Scatus:  in 

Status      typ's.        Threat:        in      Threat      Typ^, 

Engagement -Plan :    out    Engagement- Plan-Type) ; 

Frocedura    Prob-cf-Acquisition    (Engagement-Plan:      in   out 

Engagement -Plan-Typs )  ; 
Frocedura    Uncertainty- Ellipse    (Engagement-Plan:      in   cut 
Engagement -Plan_type) ; 
End    Auto-Engagement 


Package    Kanual-Engagement   is 

Frocsdure    M-Engagement       (Launcher-Missile     Status; 

Status-Type,  Engagement-Plan: 

Engagement -Plan-Type) ; 
End    Manual-Engagement 


m 
out 
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PacJsa^S   Display    is 

Task   Mena-Display  is 

entr^    Access    (Menu:    oat    Manu-Typs) 
End      Mena-Display 
Task   Launcher-Missile- Statas   is 

entry        Access  (Launchsr-Missils-Status :  out 

Status-Type) 
End      Launcher-Missile-Status 
Task  Ervironment   is 

entry    Access    (Environment:    out   Environment-Type) 
End     Environment 
Task   Ship- Parameter   is 

®I1^1  Access  (Ship-Parameter:  out 

Ship -Par  a  met  er-  Type) 
End      Ship -Parameter 
Task  Track    is 

entry    Access    (Track:    cut  Track-Type) 
End     Track 
Task  Threat   is 

€ ntr y    Access    (Threat:    out  Threat-Type) 
End     Threat 
Task   Engagement-Plan  is 

entry  Access  (Engagement-Plan:  out 

En  ga  ge  me  nt-P  la  n  -Ty  pe ) 
End     Engagement-Flan 
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Package  En  gage  merit- Display  is 

Procedure    Manual- Engage-Display       (Engagement-Flan : 

in   out      Engagemant-Plan-Type,      Threat: 

in   out   Threat-Type)  ; 
Procedure    Auto-Engage-Display  (Engagement-Plan : 

in   out      Engagemsnt-Plan-Ty  pe ,      Threat: 

in   out   Threat-Type)  ; 
Procedure   Graphics        (Engagement-Plan:  in        out 

Engagement -Plan -Type) 
End      Engagement    Display 
End   Display 
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Fackagi   Da^a  Base  Managers    is 

Facka^ge  Launcher  Missile   Staxus    Manager    is 
Type   Status  Type    is 
Record 

Empty  :      Bcolaan 

Miss    Type:      Spring   range    A   ..     C; 
End    record 
Task    Launcher   Missile   Status  is 

entry  Update    (Launcher    Missile    Status  in 

Status  Type) 
entry      Access    (Launcher      Missile      Status 
out:   Status    Type) 
End  Launcher  Missile   Status 
End   launcher  Missile  Status   Manager 
Package  Ship  Parameter    Manager   is 
Type   Ship    Fara  meter   Type  is 
Record 


Integer   range    0..359; 
Integer   range    0..50; 
L  ati-ude; 
Longitude ; 


Course 
Speed 

Position   Lat 
Position   Lcng 
End    record 
Task   Ship    Parameter   is 

entry  apdate      (Ship   Parameter 

Parameter  Type) 
entry   Access    (Ship      Parameter 
Parameter   Type) 
End  Ship    Parameter 
End   Ship  Parameter   Manager 


in   Ship 
cut   Ship 
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FackaaS  Environment    Manager    is 
Type   Environment    Type   is 
Record 

Visibility 
Sea-Sta  te 
Wind   Dir 
Wind   Spd 
Temperature 
Barometric 


Re  al    Range    0. . 30 ; 
Integer   range    0..5; 
Integer    range    0..359; 
Integer   range    0..100; 
Integer   range   -100..  150 
Integer    range    900.. 1200 


Task    Envir cement    is 

entry      Update    (Environment: 

Type) 
entrx   Access       (Environment: 
Type) 
End  Envirorment 
End   Environment    Manager 
iScka^e  Threat    Manager    is 
Type   Threat  Type    is 
Record 

Ship  Name  :  String; 
Ship  Class  :  String; 
Weapons  :      String; 

ECM  Equip  :  String; 
Attack    Plan    :      String; 


in      Envircr.ment 


out      Environment 


End    record 

Task   Threat  is 

entry    Update     (Threai::    in    Threat  Type) 

entry    Access    (Threat:    out   Threat    Type) 
End  TST^St 
End  Tlifeat    Manaoer 
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Boolean ; 

String ; 

Integer    range    0.359; 

Integer   range    C..500; 

Latitude; 

Longitude; 

Integer    range    0..359; 

Integer   range    0,.50; 


Package  IracJc    Manager    is 
Type   Track    is 
Record 

Type   Track 
Class   Vessel 
Hearing 
Hange 

Position   Lat 
Position   Long 
Course 
Speed 
End    record 
Task    Track    is 

entry   Add    (Track:    in   Track   Type) 
entry    Delate    (Track:    in    Track    Type) 
entr^    Modify    (Track:    in   Track    Type) 
entry    access    (Track:    o  u^    Track   Type) 
End  Track 
End   Track    Manager 
Packa^ge  Menu  Manager  is 
Type    Menu    is 
Record 

Undetermined    ar   t-his   time 
End    record 
Task    Menu    Display    is 

entry    Access     (Menu:    out   Menu   Type) 
End  Menu    Display 
End    Menu  Manager 
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Eacka^e  Engagement    Plan   Manager    is 
Type   Engagement  Plan   is 
Record 

Track  Desig 
Type   Plan 
Num   Missiles 
Sequence 
Miss    Type 


String ; 

Boolean  ; 

Integer  range  0..24; 

Array; 

String  range  A..C; 


End    record 
Task    Engagement   Plan   is 

entry    Access     (Engagement    Plan:    out    Engagemsnt 
Plan  Type) 
End   Engagement    Flan 
End   Engagement    Plan   Manager 
End    Data   Ease   Manager 
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APPENDIX    2 
HSCLCS   SAHELE    SOFTHARE   SP2CIFICATI0HS 

Sample        sof-ware        specifications        for        HSCLCS        from 
[Ref.    13]. 

QPil^iioLal   Data/Inf crmatioD  Requirement 

Baseline     2®§i5Il    Goal 
la.    Surface   Contact    Position  10  20  (min) 

(rance/bearing)  . 
The    use   of    bearing  line    in 
addition  to    the    lb  requirement 
reduces   the    number  of  displayed 
surface   contacts    by  two    per 
tearing    line. 

-Designated   Target  X 

Target   Category    and   Classifi- 
cation  Displayed. 

-Unintended   Target  (s)  X 

Target   Category    and   Classifi- 
cation  Displayed. 

lb.    Surface    Co  n  tact/ Hear  in  g    Line 

2.  Own    Ship  Position 

3.  Air   Contact    Position 

U.      3rd    Party  Targeting   Data  Source 
Designation 

WCIP   shall    resolve  target    position 
based   on  range   and  bearing   input 
from   3rd  party   or   bearing   lines 
from    3rd  oarties    or   own    shio. 
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1 

3 (min) 

X 

1 

3  (min) 

2 

3 (min) 

•Manual   Entry   of    Bearing    Lines  X 

•Manual    Entry  of    5ange  and   Bearing  X 

Target   Classification 
•Large    (default)  X 

Larger   than    a   patrcl   boat. 
•Small  X 

Patrcl   teat    or    smaller. 

Contact/Track  Course   Direction 

Indicator 

Program   automatically  compensates 

for   own    ship's    motion. 

•Direction  Indicator  X 

•Dead    Becloning    (Own   Ship   Only)  X 

Ccntact/Track  Targeting    Data    Sourc2 
•Manaal    Input  X 

With   appropriate   data  source    error; 
includes  3rd   party, 
•Automatic  Input 

-NTCS  X 

-FAEflE  X 

-SONAR  X 

-EW/ESM  X 

-Tarcet  Designation   System  X 

Wind   Barameters     (relative) 
Speed 
-Actual  X 

Manual  input. 
-Default  value  X 

Direction 
-Actual  X 

Manual  input. 
-Default  value  X 
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9.  Temperature 

-Actual  X 

Manual    input. 
-Default    value  X 

10.  Precipitation 

-Yes  X 

Manual   input. 
-Nc    (default    value)  "X 

11.  Operator  Cues/Lockouts 

-Launch    Inhibited    (lockouts/cua)  X 

All    launch    inhibits   except   roll/ 
pitch  cutout. 
-Missile   Ready    (cue)  X 

-Data    Age    (cue)  X 

Target   and    envircr.menta  1   data. 
-Missile   Launch    Status    (cue) 

-Call/Sail    Empty    (missile   away)  X 

-Missile  Dud  Declaration  X 

-New   Contact/Track  to    be    Input    (cue)         X 

-Illegal    Action     (lockout /cue)  X 

12.  Time/Clock 

-ZOLU   Time  X 

Start   clock:    Autciatic    entry    via 
NTDS    Interface    and/or   manual   entry. 

-Time  on   Target  X 

Manual   entry. 

-Time   of   Launch  X 

Computation. 

-Countdown  X 

Includes  lime-to-Fire  and 
Time-tc- Impact. 

13.  Loadout   Status/Missile    Variant 
Identification 
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-Eas'?lin«/Block    I   Tactical   Missils  X 

(RGM-84A) 
-Royal   Navy    Submarine    HAEPOON  X 

(EGM-84B) 

When   reconfigured  for  surface 

launch. 
-Block  IB  Tactical  Missile  X 

(EGM-aac) 

-Block  IC  Tactical  Missile  X 

(HGM-6UD) 
-Supplemental   Identification  X 

(manual    entry:    info   from   Icadour 

logbooks  Df    hybr id/ncns tan dar d 

seeker-MGU    combinations). 
-Training  All-Up    Rcund    (RTM-8UA/C/D  X 

and    ENSH) 

14.  Missile   In-Flight  Tracks  X 

15.  Up   to    180   degree   Off-Axis   Launch  X 

Qpsmtional   Selections 

1.  Reference   System 

-Trua   Target    Bear  ing/Rel  a-cive   Target        X 

Range 

Top  of    display    is  north. 
-NTDS    Grid  X 

-Geographic    (latitude   &    longitude)  X 

2.  Planned   Missile    Flight    Path  3 
Software  to    ensure  that    no   flight  WPS 
path   may  be    selected   which   could 

result    in  the  acquisition   of    own 
ship. 

3.  Search   Mode    Selection 
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-On   Line    Sizing    (default)    w/Manual  X 

Override 

On   Line   Sizing    shall  be    automa-c- 

ically   selected    if  RBL    or    BOL    are 

net    selected, 
-Range   and   Bearing  Launch    (RBL)  X 

RBL    pattern    size   shall    be      a 

function  of    total   flight   pa::h 

(range   -raveled   tc  target)  . 
-Bearing    Only   Launch    (BOL)  X 

4.  Selecrable    Search  Pattern    Expansion 

(0   -    360  degrees)  X 

For    RGM-84D    missile   only,    applies 
to   REI   mode    and    Cc-Line -Sizing 
(OLS)    which    results   in    an    RBL 
search   pattern. 
-Normal   Center  Expansion  X 

For    EGM-8UA/BGM-84E/RGM-84C 
missiles;    default  for  RGM-84D 
missile. 

5.  Enable   and    Destruct   Ranges  BOL  X 
Default   values    or  manual  entry 
(ranges   not    supplied   over    NTDS 

interface)  . 

6.  High    Altitude  Hold 
RGM-eUD   only. 

-No   Entry;    Default  X 

The    High  Altitude  Hold    default 
range  not  to   interfere    with   search 
initiation    and    net  to  exceed    lOnm ; 
i.e..   High    Altitude   Hold  range  is 
set   tc   the    minimuni  of   1  Onm   or   range 
to   search  initiation. 
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-Manual  Entry  X 

The  selected  High  Altitude  Hold 
range  must  be  less  than  the  range 
tc  search  initiation. 

7.  Presearch  Fly-Out 

-Sea    Skim    {HGM-84D  only)  X 

Default    mode   -    Presearch    Fly-Ouc    is 
set   to    sea    skim    altitude   following 
the    High  Altitude  Hold. 

-Manual   Entry  X 

Presearch   Fly-Out   at   normal    HAHPOON 
run-in   altitude    as  used    in  current 
HSCLCS. 

8.  Terminal  Attack    Mode    (RGM-84D   only) 
-Sea   Skim    (default)  X 
-Pcp-up  X 

Default   override   fcy   manual   selec- 
tion   of    pop -up,     "SMALL    TAEGET" 
designation    by    NTDS,    or    when 
"SMAII   TARGET"   is  entered   manually. 

9.  Missile   Assignment  for    Engagement 
Planning  X 
Manual   entry. 

10.  Multi-Missile   Engagement   of  4 
Designated   Target. 

Baseline:    Up   to    U  missiles  from   a 
single   launcher.     (Note:    Single 
launcher  includes  TARTAR      and 
ASROC)  .    Design    Goal:    Up    to    8 
missiles  from  2    CML's. 
-Salvo   Missiles   Against    One   Target  X 

For   Simultaneous    Arrival    (STOT 
Salvo) . 
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Operator-planned   engagement. 

-Salvo   Against  Up   to   Four  Targets  X 

(single   air  point)    From    One   Launcher 
For    Simultaneous    Arrival    (STOT 
Salve) . 

Same    aimpoint  and  a   different   RBL 
search   expansion    for   each    RGM-84D 
missile    in    order   to  distribute 
saivoed   missiles    among    the   targe's 
in   a   formation. 

-Ripple    Salvo   as    per   current    HSCLCS  X 

CML   Configuration. 

-Quick   Reaction/Preprogrammed    STDT  X 

Salve. 

Modified  HSCLCS    automatically   will 
calculate  and  enter  a   different 
waypoint  for   each   RGM-8i*D   missile 
in   a   guide    reaction  salvo   for 
simultaneous  time-on -target    (STOT). 

11.    Background    data    and   sector  data  X 

reguest . 
Dsatlc   with    NTDS    interface  only. 

ENGAGEMENT    DISPLAYS 

1.  Contact/Track  Uncertainity   Ellipse 
-Designated   Surface  Target  X 
-Unintended   Targets  X 

If   selec-ed    by    operator. 

2.  Predicted  Time-on-Target  X 

3.  Probabili-y    of    Acguisition 
Numerical  value. 

-Designated   Targets  X 

-Unintended    Targets  X 
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If   3€l€cted    by    opera ror. 

4.  S€ek<=r   Search   Pattern  Outline  X 
For   selected   search   mode, 

5.  Missile    Flight    Path  X 
For    all   selected    lissiles. 

6.  Booszer    Drop   Zone  X 

7.  Missile   Power  Application    Warning  X 

OTHER 

1.  Test/Maintenance 
-Missile  BIT  Results 

-Go/Nc-Go  Indication  X 

-Failure  Status  Coda  X 
-HSCLCS  BIT  Results 

-Go/Nc-Go  Indication  X 

-Failure  Status  Cede  X 

2.  Training  Mode 

Inherent  capability   provided    by 
system   design.    Design  to   utilize 
data    from  NTDS    and/or  external 
training  support    devices   via   an   RS 
232   serial    interface. 

-Contact/Track   Location     (actual   or 
simulated)  . 

-Cff    Board    Source/NTDS  X 

-Own   Ship  Sensor s/NTDS  X 

-Manual   Input  X 

-Own    Ship  Position    (actual   or    simul-         X 
ated)  . 

-Training  Scenario   Parameters 
-Environmental    Ccrditions  X 

-Operational  Planning   Selections  X 
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3.  Data    Extract 

Design   to  be  compatibla    with   an   RS 
232    serial    interface  to    provide    for 
data   storage/display   in    off-line 
devic«=s    (e.g.,    tape   cassette   recor- 
der). 
-Target/Targeting   Data  X 

-Missile    Ini-cialization    Data  X 

-BIT    Results  X 

4.  Major   Display  Features 

-Variatle  Range    Scale  X 

16K-,    32K-,     eUK",    123K-,     192K-,    or 
256K-yard  radius.   The   256K-yard   is 
the   default    scale. 
-Offset  X 

-Zoom  X 

8K-,    16K-  or   32K-yard   radius. 
-Special   Symbols  X 

-Cursor,    with  Bearing/Range   raaiout  X 

Manually  controlled. 


134 


APPEHDIX    ? 
HSCLCS   SYSTEfl    DIAGRAMS 

These    four    diagrams    illusrrars   the   current  configuration 
of    the   HSCLCS  and  the  new   proposed  one. 
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Figure  P.I 


Hardware  COMponent  OvecTiew  cf  HAHPOOH  Weapon  System. 

136 


n 


DATA  (HTRT 


260 

i  Tint 

1  Kucr 
1  If  AtmG 

D  t.lMT  1 

117 

(UOTAaot 

1     lOl 

1    I>ui 

1     IIAfllMC 

246 

U«Mt 

121 

oinnucT 

■USl 

tllOTAIOI 

81AKINC  INOlC/ktOR 


SrjTE"  STATUS 


MIUILl  MOOC 

SCAMCH^ATTriH 


P 

ll 

xoww 

_Z1 

U»GC 

auii 

I 

•Oi 

QBE] 
EHEl 


Uuto       0 


ouiof  i 


nmiu  f  AMU 


0»» 

A 


E 


CAUCfl) 
UCACCI 

U 1 


HEIOMT: 
WIDTH; 


21    la. 

11  la 
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Figure   F.3 


Propcsed  Cannister  Launch   HSCLCS    WCIP. 
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Figure  F.4   Saapla  Display  from  Proposed  'rfCIP. 
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